예를 들어 OrderId.create는 문자열에서 OrderId를 생성하거나 문자열이 잘못된 형식인 경우 오류를 발생시킵니다.
Wrapper 타입 내부의 primitive 값을 추출하는 값 함수
일반적으로 이러한 헬퍼 함수는 단순 타입과 동일한 이름을 가진 모듈을 사용하여 단순 타입과 동일한 파일에 넣습니다.
예제 : 다음은 도메인 모듈의 OrderId에 대한 정의와 헬퍼 함수입니다.
//>SimpleTypes1
module Domain =
type OrderId = private OrderId of string
module OrderId =
/// Define a "Smart constructor" for OrderId
/// string -> OrderId
let create str =
if String.IsNullOrEmpty(str) then
// use exceptions rather than Result for now
failwith "OrderId must not be null or empty"
elif str.Length > 50 then
failwith "OrderId must not be more than 50 chars"
else
OrderId str
/// Extract the inner value from an OrderId
/// OrderId -> string
let value (OrderId str) = // unwrap in the parameter!
str // return the inner value
//<
create 함수는 지금은 효과를 피하고 있기 때문에 Result type을 반환하는 대신 오류에 대해 예외(failwith)를 사용한다는 점을 제외하면 설계와 유사합니다.
value 함수는 매개변수를 이용해 한 단계 패턴 매치를 수행 후 추출합니다.
함수 타입을 구현 지침으로 사용하기
모델링 장에서 워크플로의 각 단계를 나타내는 특수 함수 타입을 정의했습니다.
이제 구현할 시간입니다. 코드가 이를 준수하도록 하려면 어떻게 해야 할까요?
가장 간단한 접근 방식은 정상적인 방법으로 함수를 정의하고 나중에 사용할 때 잘못되면 타입 검사 오류가 발생할 것이라고 신뢰하는 것입니다.
예를 들어 이전에 디자인한 ValidateOrder 타입에 대한 참조 없이 아래와 같이 validateOrder 함수를 정의할 수 있습니다.
이것은 대부분의 F# 코드에 대한 표준 접근 방식이지만 특정 함수 타입을 구현하고 있음을 명확히 하려는 경우 다른 스타일을 사용할 수 있습니다.
함수 타입을 애너테이션으로 활용하여 함수를 작성할 수 있고 함수 본문은 람다로 작성할 수 있습니다.
(주 : DotDotDot은 IDE 빨간줄을 피하기위한 PlaceHolder로 ...를 의미합니다. 지금은 디테일이 중요한게 아니니까요.)
type Param1 = DotDotDot
type Param2 = DotDotDot
type Result = DotDotDot
(*
"if we want to make it clear that we are implementing a specific function signature"
*)
//>UsingFunctionSignatures2
// define a function signature
type MyFunctionSignature = Param1 -> Param2 -> Result
// define a function that implements that signature
let myFunc: MyFunctionSignature =
fun param1 param2 ->
dotDotDot()
//<
이 접근 방식을 validateOrder 함수에 적용해봅시다.
type ValidateOrder =
CheckProductCodeExists // dependency
-> CheckAddressExists // dependency
-> UnvalidatedOrder // input
-> Result<ValidatedOrder,ValidationError list> // output
(*
"Applying this approach to the `validateOrder` function gives us:"
*)
//>UsingFunctionSignatures3
let validateOrder : ValidateOrder =
fun checkProductCodeExists checkAddressExists unvalidatedOrder ->
// ^dependency ^dependency ^input
dotDotDot()
//<
이것의 좋은 점은 모든 매개변수와 반환 값이 함수 타입에 따라 결정되는 타입을 가지므로 구현에서 실수를 하면 함수 정의 내부에서 로컬로 오류가 발생한다는 것입니다. 함수를 조합할 때도 마찬가지입니다.
실수로 checkProductCodeExists 함수에 정수를 전달하면 타입 체킹 시 오류가 발생합니다.
let validateOrder : ValidateOrder =
fun checkProductCodeExists checkAddressExists unvalidatedOrder ->
if checkProductCodeExists 42 then
// compiler error ^
// This expression was expected to have type ProductCode
// but here has type int
...
...
매개변수의 타입을 결정하기 위한 함수 타입이 없으면 컴파일러는 타입 추론를 사용하며 checkProductCodeExists가 int를 파라미터로 동작한다고 결론을 내릴 수 있습니다. 그러면 나중에 의존성 주입 시 오류가 발생할 것입니다. (ProductCode Wrapper 타입을 파라미터로 사용하기 때문)
Order의 유효성 검사 구현
검증 단계는 모든 기본 필드와 함께 검증되지 않은 데이터를 취하고 이를 적절하고 완전히 검증된 도메인 객체로 변환합니다.
문제가 생겼습니다. toProductCode 함수가 ProductCode를 반환하기를 원하지만 checkProductCodeExists 함수는 bool을 반환합니다. 이는 전체 파이프라인이 bool을 반환함을 의미합니다. 어떻게든 checkProductCodeExists가 대신 ProductCode를 반환하도록 해야 합니다. 이런, 스펙을 바꿔야 한다는 뜻인가요? 다행히 방법이 있습니다.
(주 : 위의 CheckAddressExist 종속성은 Wrapping된 주소 자체를 반환했었습니다.
어댑터 함수 만들기 (Creating Function Adapters)
bool을 반환하는 함수가 있지만 원래 ProductCode 입력을 반환하는 함수가 필요합니다.
사양(타입 목록)을 변경하는 대신
원래 함수를 입력으로 사용하고 파이프라인에서 사용할 올바른 "모양"으로 새 함수를 내보내는 "어댑터" 함수를 만들어 보겠습니다.
어댑터 함수
다음은 bool 반환 predicate(checkProductCodeExists) 및 확인할 값(productCode) 매개변수가 있는 명백한 구현입니다.
우리는 이것을 "당신은 나에게 오류 메시지와 'a -> bool 유형의 함수를 제공하고, 나는 'a -> 'a 유형의 함수를 돌려줄 것입니다."로 해석할 수 있습니다. 따라서 이 predicateToPassthru 함수는 "함수 변환기"입니다. 하나의 함수에 입력하면 다른 함수로 변환됩니다.
(주 : x까지 3개의 인자를 동시에 제공할 수도 있습니다.)
이 기술은 함수형 프로그래밍에서 매우 일반적이므로 무슨 일이 일어나고 있는지 이해하고 패턴을 볼 때 인식하는 것이 중요합니다.
소박한 List.map 함수도 함수 변환기로 생각할 수 있습니다. "일반" 함수 'a -> 'b를 목록에서 작동하는 함수('a list -> 'b list)로 변환합니다.
이제 이 일반 함수를 구현에 사용할 수 있는 새 버전의 toProductCode를 생성해 보겠습니다.
let toProductCode (checkProductCodeExists:CheckProductCodeExists) productCode =
// create a local ProductCode -> ProductCode function
// suitable for using in a pipeline
let checkProduct productCode =
// 에러 메세지 표현식
let errorMsg = sprintf "Invalid: %A" productCode
// 위의 에러 메세지를 인자로 제공
predicateToPassthru errorMsg checkProductCodeExists productCode
// assemble the pipeline
productCode
|> ProductCode.create
|> checkProduct
이제 우리는 구축할 수 있는 validateOrder 구현의 기본 스케치를 갖게 되었습니다.
"제품은 W 또는 G로 시작해야 함"과 같은 저수준 유효성 검사 논리는 유효성 검사 함수에서 명시적으로 구현되지 않고
OrderId 및 ProductCode와 같은 제한된 단순 타입의 생성자에 내장되어 있습니다.
타입을 사용하면 코드가 정확하다는 확신을 높일 수 있습니다.
UnvalidatedOrder에서 ValidatedOrder를 성공적으로 생성할 수 있다는 사실 자체가 유효성이 검증되었다는 것을 신뢰할 수 있다는 것을 의미합니다!
나머지 스텝 구현하기
이제 validateOrder를 구현하는 방법을 보았으므로 동일한 기술을 사용하여 나머지 파이프라인 함수를 빌드할 수 있습니다.
접근 방식을 사용하여 함수 타입을 준수하는 특정 파이프라인 단계의 더미 버전을 빌드한 다음 적절한 구현을 사용할 수 있기 전에 다른 단계와 함께 사용할 수 있습니다.
priceOrder 구현으로 돌아가서 두 가지 새로운 도우미 함수인 toPricedOrderLine 및 BillingAmount.sumPrices를 도입했습니다.
BillingAmount.sumPrices 함수를 공유 BillingAmount 모듈에 추가했습니다. (create 함수 및 value 함수와 함께)
단순히 가격 목록을 추가하고 BillingAmount로 래핑합니다.
처음에 BillingAmount 타입을 정의한 이유는 무엇입니까?
계산 결과가 가격과 다르고 유효성 검사 규칙이 다를 수 있기 때문입니다.
/// Sum a list of prices to make a billing amount
/// Raise exception if total is out of bounds
// type GetProductPrice = ProductCode -> Price
let sumPrices prices =
let total = prices |> List.map Price.value |> List.sum
create total
toPricedOrderLine 함수는 이전에 본 것과 유사합니다. 한 줄만 변환하는 도우미 함수입니다.
그리고 이 함수 안에 Price.multiply라는 또 다른 도우미 함수를 도입하여 Price에 수량을 곱했습니다.
이제 OrderPlaced 이벤트, Optional OrderAcknowledgementSent 이벤트 및 Optional BillableOrderPlaced가 있습니다.
어떻게 반환해야 합니까?
우리는 모든 것을 공통 유형으로 변환하기 위해 "최소 공배수" 접근 방식을 사용할 것입니다.
우리는 전부를 포함한 초이스 타입(PlaceOrderEvent)을 생성한 다음 그 리스트를 반환하기로 결정했습니다.
따라서 먼저 각 이벤트를 초이스 타입으로 변환해야 합니다.
OrderPlaced 이벤트의 경우 PlaceOrderEvent.OrderPlaced 생성자를 직접 사용할 수 있지만
OrderAcknowledgementSent 및 BillableOrderPlaced의 경우 선택 사항이므로 Option.map을 사용해야 합니다.
let createEvents : CreateEvents =
fun pricedOrder acknowledgmentEventOpt ->
let event1 =
pricedOrder
// convert to common choice type
|> PlaceOrderEvent.OrderPlaced
let event2Opt =
acknowledgmentEventOpt
// convert to common choice type
|> Option.map PlaceOrderEvent.AcknowledgmentSent
let event3Opt =
pricedOrder
|> createBillingEvent
// convert to common choice type
|> Option.map PlaceOrderEvent.BillableOrderPlaced
// return all the events how?
...
이제 모두 같은 초이스 타입이지만, 일부는 Option 타입에 감싸져있네요.
우리는 같은 트릭을 다시 수행합니다. 즉 Option<타입>을
다시 일반적인 타입으로 변환할 것입니다. 이 경우에는 리턴 타입인 리스트 입니다.
OrderPlaced의 경우 List.singleton을 사용하여 리스트로 변환할 수 있으며 옵션의 경우 listOfOption이라는 도우미를 만들 수 있습니다.
/// convert an Option into a List
let listOfOption opt =
match opt with
| Some x -> [x]
| None -> []
타입 리뷰
type OrderPlaced = PricedOrder
/// Event to send to billing context
/// Will only be created if the AmountToBill is not zero
type BillableOrderPlaced = {
OrderId : OrderId
BillingAddress: Address
AmountToBill : BillingAmount
}
type PlaceOrderEvent =
| OrderPlaced of OrderPlaced
| BillableOrderPlaced of BillableOrderPlaced
| AcknowledgmentSent of OrderAcknowledgmentSent
type CreateEvents =
PricedOrder // input
-> OrderAcknowledgmentSent option // input (event from previous step)
-> PlaceOrderEvent list // output
//<
이제 세 가지 이벤트 타입이 모두 동일하고, 각각 다른 목록에 반환할 수 있습니다.
let createEvents : CreateEvents =
fun pricedOrder acknowledgmentEventOpt ->
let events1 =
pricedOrder
// convert to common choice type
|> PlaceOrderEvent.OrderPlaced
// convert to list
|> List.singleton
let events2 =
acknowledgmentEventOpt
// convert to common choice type
|> Option.map PlaceOrderEvent.AcknowledgmentSent
// convert to list
|> listOfOption
let events3 =
pricedOrder
|> createBillingEvent
// convert to common choice type
|> Option.map PlaceOrderEvent.BillableOrderPlaced
// convert to list
|> listOfOption
// return all the events
[
yield! events1
yield! events2
yield! events3
]
호환되지 않는 항목들을 공유 타입으로 변환하거나 "리프팅"하는 이러한 접근 방식은 함수 합성 문제를 처리하는 핵심 기술입니다.
예를 들어, 다음 장에서는 다른 종류의 Result type 간의 불일치를 처리하는 데 사용할 것입니다.
