Domain Modeling Made Functional

서문

이 책은 누구를 위한 책인가?

• 대상 독자: 새로운 도구를 도구 벨트에 추가하고 싶은 경력 있는 소프트웨어 개발자
• 다음 중 하나에 해당하면 추천되는 책
  • 타입과 함수만으로 도메인을 모델링/구현하는 방법이 궁금한 사람
  • 도메인 주도 설계(DDD)를 객체지향 설계나 DB 우선 설계와 비교하며 쉽게 배우고 싶은 사람
  • 이미 DDD 실무자이며, DDD가 함수형 프로그래밍과 왜 잘 맞는지 알고 싶은 사람
  • 이론과 추상화에 지쳐 실용적인 함수형 프로그래밍 입문서를 원하는 사람
  • F#과 함수형 프로그래밍이 실제 도메인에 어떻게 적용되는지 보고 싶은 사람
• 사전 지식: DDD나 함수형 프로그래밍 경험이 없어도 무방함 (입문서 성격이며 필요한 개념은 그때그때 설명)

이 책에는 무엇이 담겨 있는가?

• 책 전체는 3부 구성이며, 각 파트는 이전 파트를 기반으로 하므로 순서대로 읽는 것을 권장
  1. 파트 1: 도메인 이해하기 (Understanding the Domain)
  2. 파트 2: 도메인 모델링하기 (Modeling the Domain)
  3. 파트 3: 모델 구현하기 (Implementing the Model)

파트 1 (도메인 이해하기)

• DDD의 배경 개념과 도메인에 대한 공유된 이해의 중요성을 다룸
• Event Storming 같은 공유 이해 구축 기법을 간략히 살펴봄
• 큰 도메인을 독립적으로 구현/진화 가능한 작은 컴포넌트로 분해하는 방법을 다룸
• DDD 전체를 철저히 다루는 책은 아니며, 다음 두 가지를 강조
  • (a) 도메인 전문가 및 비개발 팀원과의 소통 중요성
  • (b) 실세계 개념에 기반한 공유 도메인 모델의 가치

파트 2 (도메인 모델링하기)

• 도메인에서 워크플로우 하나를 골라 함수형 방식으로 모델링
• 객체지향적 분해 방식과 함수적 분해 방식의 차이를 비교
• 타입으로 요구사항을 표현하는 방법을 학습
• 결과물: 도메인의 읽기 쉬운 문서 역할을 하면서, 동시에 컴파일 가능한 구현 프레임워크가 되는 코드

파트 3 (모델 구현하기)

• 같은 워크플로우를 실제로 구현
• 합성(composition), 부분 적용(partial application), “모나드(monad)” 같은 함수형 기법 학습
• 완전한 함수형 프로그래밍 가이드는 아니며, 도메인 구현에 필요한 만큼만 다룸
• 마지막 챕터에서는 요구사항 변화에 따라 설계가 어떻게 진화할 수 있는지 다룸

도메인 모델링에 대한 다른 접근법

• 이 책은 데이터 구조를 정의하고 그 위에서 동작하는 함수를 정의하는 “주류(mainstream)” 방식에 집중
• 다른 상황에 더 적합할 수 있는 접근법 2가지를 소개(깊이 다루지는 않음)
  1. 반구조적(semistructured) 데이터 중심 도메인 → 이 책에서 다루는 경직된 모델이 부적합할 수 있으며, 맵/딕셔너리 같은 유연한 구조가 더 나은 선택 (Clojure 커뮤니티가 이 부분에 강함)
  2. 원소를 조합해 다른 원소를 만드는 것이 핵심인 도메인 → 데이터보다 “조합 규칙(대수, algebra)“에 먼저 집중하는 것이 유용. 금융 계약, 그래픽 디자인 툴 등 “everywhere composition” 도메인은 함수형 접근에 특히 적합하지만, 지면 관계상 본문에서는 다루지 않음

파트 1 도메인 이해하기

• 이 파트에서는 DDD의 배경이 되는 아이디어와, 도메인에 대한 공유된 이해가 왜 중요한지를 다룸
• 이런 공유된 이해를 구축하는 데 도움이 되는 기법으로 Event Storming을 간략히 살펴봄
• 이후 큰 도메인을 독립적으로 구현/진화 가능한 더 작은 컴포넌트로 분해하는 방법을 살펴봄

챕터 1 도메인 주도 설계 소개

• 개발자의 역할에 대한 핵심 주장: 개발자의 일은 단순히 “코드를 작성하는 것”이 아니라 소프트웨어를 통해 문제를 해결하는 것이며, 코딩은 그 일부일 뿐임. 좋은 설계와 커뮤니케이션이 그만큼(혹은 그 이상) 중요함
• 소프트웨어 개발을 입력(요구사항)과 출력(최종 산출물)이 있는 파이프라인으로 비유하면 “Garbage in, garbage out” 원칙이 적용됨 → 입력(불분명한 요구사항, 나쁜 설계)이 나쁘면 아무리 좋은 코딩 실력으로도 좋은 결과물을 만들 수 없음
• 이 책 파트 1의 목표: 명확한 커뮤니케이션과 공유된 도메인 지식에 초점을 맞춘 설계 접근법인 **도메인 주도 설계(Domain-Driven Design, DDD)**를 통해 “garbage in”을 최소화하는 방법을 다룸
• DDD는 매우 큰 주제이므로 이 챕터에서 깊이 있게 다루지는 않음(자세한 내용은 dddcommunity.org 참고). 이 챕터를 마치면 DDD가 어떻게 작동하는지, 그리고 DB 주도 설계 및 객체지향 설계와 어떻게 다른지 감을 잡을 수 있는 것이 목표
• DDD가 모든 소프트웨어 개발에 적합한 것은 아님 (시스템 소프트웨어, 게임 등은 다른 접근이 더 나을 수 있음). 다만 개발자가 비개발 팀과 협업해야 하는 비즈니스/엔터프라이즈 소프트웨어에 특히 유용하며, 이것이 이 책의 초점

1.1 공유 모델의 중요성

• 문제를 풀기 전에 문제를 정확히 이해하는 것이 먼저다. 이해가 불완전하거나 왜곡되면 유용한 해결책을 제공할 수 없음
• 안타깝게도 실제 프로덕션에 반영되는 것은 도메인 전문가의 이해가 아니라 개발자의 이해임
• 그렇다면 개발자가 문제를 제대로 이해하고 있다는 것을 어떻게 보장할 수 있을까?

접근 방식 1: 문서(명세서) 기반 접근

• 일부 개발 프로세스는 문서화된 명세/요구사항 문서로 문제의 모든 세부사항을 포착하려 시도
• 문제는, 이 접근이 문제를 가장 잘 아는 사람(도메인 전문가)과 솔루션을 구현할 사람(개발팀: 개발자뿐 아니라 UX/UI 디자이너, 테스터 등 포함) 사이에 거리를 만든다는 것

flowchart LR
    A["도메인 전문가"] --> B["비즈니스 분석가"]
    B --> C["요구사항 문서"]
    C --> D["아키텍트"]
    D --> E["설계 문서"]
    E --> F["개발팀"]
    F --> G["코드"]

• 이 과정은 어린이 놀이 “전화(Telephone)” 게임에 비유됨: 메시지가 사람을 거칠수록 점점 왜곡됨
• 실제 개발 프로젝트에서는 전혀 재미있는 일이 아니며, 개발자의 이해와 도메인 전문가의 이해 사이의 불일치는 프로젝트 성공에 치명적일 수 있음

접근 방식 2: 반복적(애자일) 피드백 루프

• 더 나은 해결책은 중간 단계를 없애고, 도메인 전문가를 개발 프로세스에 긴밀히 참여시켜 개발팀과 도메인 전문가 사이에 피드백 루프를 만드는 것
• 개발팀이 도메인 전문가에게 정기적으로 무언가를 전달하면, 도메인 전문가는 다음 이터레이션을 위해 오해를 빠르게 바로잡을 수 있음

flowchart LR
    A["도메인 전문가"] <--> B["개발팀"]
    B --> C["코드"]
    C --> D["산출물(deliverable)"]
    D --> A

• 이런 반복적 프로세스가 “애자일” 개발 프로세스의 핵심
• 그러나 이 방식도 한계가 있음: 개발자가 도메인 전문가의 멘탈 모델을 코드로 옮기는 번역가 역할을 하게 되는데, 모든 번역이 그렇듯 왜곡과 미묘한 뉘앙스의 손실이 발생할 수 있음. 코드가 도메인 개념과 정확히 대응하지 않으면, 도메인 전문가의 입력 없이 코드베이스를 다루는 후속 개발자들이 오해하여 오류를 만들기 쉬움

접근 방식 3 (DDD): 공유 멘탈 모델

• 세 번째 접근법: 도메인 전문가, 개발팀, 다른 이해관계자, 그리고 (가장 중요하게) 소스 코드 자체가 모두 동일한 모델을 공유한다면 어떨까?
• 이 경우 도메인 전문가의 요구사항에서 코드로의 “번역”이 존재하지 않음. 코드는 공유된 멘탈 모델을 직접 반영하도록 설계됨
• 이것이 바로 도메인 주도 설계(DDD)의 목표

flowchart TD
    M(("공유 멘탈 모델"))
    A["도메인 전문가"] <--> M
    B["개발팀"] <--> M
    C["기타 이해관계자"] <--> M
    D["코드"] <--> M

공유 모델 정렬의 이점

콜아웃: 인상적으로 효과적인 딜리버리 머신

Behavior-Driven Development의 창시자로 잘 알려진 Dan North는 자신의 강연 “Accelerating Agile”에서 소규모 트레이딩 회사 팀에서의 경험을 소개했음. 그는 그 팀을 자신이 경험한 것 중 가장 인상적으로 효과적인 딜리버리 머신이라고 묘사했으며, 그곳에서는 소수의 프로그래머가 몇 주 만에 최첨단 트레이딩 시스템을 만들어냈음. 이 팀 성공의 한 가지 이유는 개발자들이 실제 트레이더들과 함께 트레이더로 훈련받아 스스로 도메인 전문가가 되었다는 점임. 그 결과 공유된 멘탈 모델 덕분에 트레이더들과 매우 효과적으로 소통할 수 있었고, 도메인 전문가(트레이더)가 원하는 것을 정확히 구현할 수 있었음

• 공유 모델을 어떻게 만들 것인가? DDD 커뮤니티가 정리한 4가지 가이드라인이 이 챕터 나머지 부분의 뼈대가 됨
  1. 데이터 구조가 아니라 비즈니스 이벤트와 워크플로우에 집중한다
  2. 문제 도메인을 더 작은 서브도메인으로 분할한다
  3. 솔루션에서 각 서브도메인의 모델을 만든다
  4. 프로젝트에 관련된 모두가 공유하고 코드 전반에서 사용하는 공통 언어, 즉 **“유비쿼터스 언어”**를 개발한다

1.2 비즈니스 이벤트를 통해 도메인 이해하기

• DDD 접근법은 개발자와 도메인 전문가 사이의 공유된 이해를 구축하는 것을 강조함. 그렇다면 어디서부터 시작해야 하는가?
• 첫 번째 가이드라인은 데이터 구조가 아니라 비즈니스 이벤트에 집중하라는 것
• 이유: 비즈니스는 단순히 데이터를 가지고 있는 것이 아니라 데이터를 어떤 식으로든 변환함. 즉 전형적인 비즈니스 프로세스는 데이터/문서 변환의 연속으로 볼 수 있음. 비즈니스의 가치는 이 변환 과정에서 창출되므로, 변환이 어떻게 작동하고 서로 어떻게 관계 맺는지 이해하는 것이 매우 중요함
• 아무도 사용하지 않고 그냥 놓여 있는 정적 데이터는 아무 가치도 만들어내지 않음. 그렇다면 무엇이 직원(또는 자동화 프로세스)으로 하여금 그 데이터를 다루며 가치를 더하게 만드는가?
  • 외부 트리거: 우편물 도착, 전화벨 등
  • 시간 기반 트리거: 매일 오전 10시에 어떤 작업을 수행
  • 관찰 기반 트리거: 수신함에 처리할 주문이 더 없으므로 다른 작업으로 전환
• 무엇이 되었든 이런 트리거를 설계에 포착하는 것이 중요함 → 이를 **도메인 이벤트(Domain Event)**라 부름
• 도메인 이벤트는 우리가 모델링하려는 거의 모든 비즈니스 프로세스의 출발점. 예: “주문서 접수됨”은 주문 접수 프로세스를 시작시키는 도메인 이벤트
• ==도메인 이벤트는 항상 과거형으로 작성됨== — 이미 일어난, 바꿀 수 없는 사실이기 때문

1.2.1 이벤트 스토밍으로 도메인 발견하기

• 도메인에서 이벤트를 발견하는 방법은 여러 가지지만, DDD 접근에 특히 적합한 것이 이벤트 스토밍(Event Storming) — 비즈니스 이벤트와 그에 연관된 워크플로우를 발견하기 위한 협업 프로세스
• 진행 방식
  • 도메인의 서로 다른 부분을 이해하는 다양한 사람들을 모아 촉진자가 이끄는 워크숍을 진행
  • 참가자는 개발자와 도메인 전문가뿐 아니라, 프로젝트 성공에 이해관계가 있는 다른 모든 사람(UX/UI 디자이너, 테스터 등)을 포함해야 함 — 이벤트 스토머들은 이를 “질문이 있는 사람과 답이 있는 사람 모두”라고 표현함
  • 워크숍은 벽면이 넓은 방에서 진행하며, 참가자들이 스티키 노트를 붙이거나 그릴 수 있도록 벽을 종이나 화이트보드 재질로 덮어야 함
  • 성공적인 세션이 끝나면 벽은 수백 장의 스티키 노트로 뒤덮임
  • 참가자들은 스티키 노트에 비즈니스 이벤트를 적어 벽에 붙이고, 다른 사람들은 그 이벤트가 촉발하는 비즈니스 워크플로우를 요약한 노트로 응답함
  • 이 워크플로우들은 다시 다른 비즈니스 이벤트를 만들어내는 경우가 많음
  • 노트들은 종종 타임라인으로 정리되며 추가 논의를 촉발함
  • 목표는 모든 참가자가 자신이 아는 것을 게시하고, 모르는 것을 질문하며 적극적으로 참여하게 하는 것
• 이벤트 스토밍에 대한 자세한 내용은 이 기법의 창시자인 Alberto Brandolini의 저서 “EventStorming”을 참고할 것

1.2.2 도메인 발견하기: 주문 접수 시스템

• 이 책 전체에서 사용할 예제 도메인: 소규모 제조업체 Widgets Inc의 주문 접수 워크플로우 자동화

• 배경 (매니저 Max의 설명 요지)

  • 다른 회사에 부품(위젯, 기즈모 등)을 제조해 공급하는 작은 회사로, 빠르게 성장하고 있지만 기존 프로세스가 물량 증가를 따라가지 못함
  • 현재 모든 프로세스가 종이 기반이며, 이를 전산화해 더 큰 물량을 처리하고 싶어함
  • 특히 고객이 주문, 주문 상태 확인 등의 작업을 직접 처리할 수 있는 셀프서비스 웹사이트를 원함

• 이벤트 스토밍 세션 진행 과정 요약 (등장인물: Ollie=주문접수부서, Sam=배송부서, Blake=청구부서, Max=매니저)

  • Ollie: 주문접수부서는 고객이 우편으로 보내오는 주문서/견적서를 주로 처리한다고 설명 → 이벤트 후보로 “주문서 접수됨”, “견적서 접수됨” 제안
  • Sam: 배송부서는 승인 완료된 주문을 이행하며, 주문접수부서로부터 주문을 받을 때 작업이 시작된다고 설명. 처음에는 “주문 이용 가능”이라는 이벤트명을 제안했으나, Ollie가 완료되어 배송 준비된 주문을 “배치된 주문(Placed order)“이라 부른다고 하면서 팀 간 용어를 **“주문 배치됨(Order placed)”**으로 통일하자고 제안 → 이 짧은 상호작용은 이벤트 스토밍 과정에서 팀 간 용어가 어떻게 하나의 언어로 수렴해 가는지(유비쿼터스 언어의 씨앗)를 잘 보여줌

• 이렇게 발견된 이벤트 목록 예시

  • 주문서 접수됨 (Order form received)
  • 주문 배치됨 (Order placed)
  • 주문 배송됨 (Order shipped)
  • 주문 변경 요청됨 (Order change requested)
  • 주문 취소 요청됨 (Order cancellation requested)
  • 반품 요청됨 (Return requested)
  • 견적서 접수됨 (Quote form received)
  • 견적 제공됨 (Quote provided)
  • 신규 고객 요청 접수됨 (New customer request received)
  • 신규 고객 등록됨 (New customer registered)

• 일부 이벤트 옆에는 “Place Order(주문하기)”, “Ship Order(배송하기)” 같은 비즈니스 워크플로우가 함께 게시되며, 이벤트들이 더 큰 워크플로우로 어떻게 연결되는지가 서서히 드러남

• 세션 전체를 다 다룰 수는 없지만, 이벤트 스토밍이 요구사항 수집에서 촉진하는 측면들을 살펴보면 다음과 같음

1. 비즈니스의 공유 모델

   • 이벤트를 발견하는 것 외에도, 모든 참가자가 같은 벽을 바라보며 비즈니스에 대한 공유된 이해를 형성한다는 것이 핵심 이점
   • DDD와 마찬가지로 이벤트 스토밍도 커뮤니케이션과 공유 모델, 그리고 “우리 vs 그들” 식의 사고를 피하는 것을 강조함
   • 참가자들은 익숙하지 않은 도메인 영역을 배울 뿐 아니라, 다른 팀에 대한 자신의 가정이 틀렸음을 깨닫거나 비즈니스 개선에 도움이 되는 통찰을 얻기도 함

2. 모든 팀에 대한 인식

   • 자신이 관여하는 한 측면에만 집중하다 보면 다른 팀도 관여하고 있으며 자신이 만드는 데이터를 소비해야 할 수 있다는 사실을 잊기 쉬움
   • 모든 이해관계자가 한 자리에 있으면, 소외될 수 있는 팀도 직접 목소리를 낼 수 있음
   • 예: 청구부서의 Blake가 자신들도 완료된 주문에 대해 알아야 청구를 하고 회사를 위해 돈을 벌 수 있다고 지적하며, 청구부서를 위한 “주문 배치됨” 이벤트도 필요하다고 언급

3. 요구사항의 공백 발견

   • 이벤트를 벽에 타임라인으로 배치하면 누락된 요구사항이 매우 명확하게 드러나는 경우가 많음
   • 예: 매니저 Max가 Ollie에게 주문 준비가 끝난 뒤 고객에게 알리는지 묻자, Ollie는 그제서야 주문이 성공적으로 배치되면 고객에게 접수 확인 및 곧 배송한다는 이메일을 보낸다는 사실을 떠올리고 “고객에게 확인 메일 발송됨” 이벤트를 추가함
   • 명확한 답이 없는 질문은 질문 자체를 벽에 게시해 추가 논의의 트리거로 삼아야 함
   • 논쟁이나 이견이 생기는 부분은 문제가 아니라 기회로 여겨야 함 — 그런 영역을 파고들면 많은 것을 배울 수 있음
   • 프로젝트 초기에는 요구사항이 흐릿한 경우가 흔하므로, 이런 질문과 논쟁을 눈에 보이게 문서화하면 아직 할 일이 남아 있음이 명확해지고 개발 프로세스가 성급하게 시작되는 것을 막아줌

4. 팀 간 연결

   • 이벤트를 타임라인으로 그룹화하면 한 팀의 출력이 다른 팀의 입력이라는 사실이 명확해지는 경우가 많음
   • 예: 주문접수팀이 주문 처리를 마치면 새 주문이 배치되었음을 알려야 하며, 이 “주문 배치됨” 이벤트는 배송팀과 청구팀 모두의 입력이 됨

flowchart LR
    subgraph OT["주문접수팀 컨텍스트"]
        A["주문서 접수됨"] --> W1[["주문하기 워크플로우"]]
        W1 --> B["주문 배치됨"]
        W1 --> C["고객에게 확인 메일 발송됨"]
    end
    subgraph SH["배송팀 컨텍스트"]
        B --> W2[["배송하기 워크플로우"]]
        W2 --> D["주문 배송됨"]
        W2 --> E["고객에게 발송 메시지 전달됨"]
    end

• 이 단계에서 팀들이 기술적으로 어떻게 연결되는지(메시지 큐 vs 데이터베이스 등)는 중요하지 않음. 도메인 자체에 집중하는 것이 목표

5. 보고 요구사항에 대한 인식
   • 프로세스와 트랜잭션에만 집중하다 보면 놓치기 쉽지만, 모든 비즈니스는 과거에 무슨 일이 있었는지 이해해야 함 — 보고(reporting)도 항상 도메인의 일부
   • 이벤트 스토밍 세션에는 보고 및 다른 읽기 전용 모델(예: UI용 뷰 모델)도 반드시 포함해야 함

1.2.3 이벤트를 경계까지 확장하기

• 이벤트 체인을 시스템의 경계까지 최대한 따라가 보는 것이 유용함. 먼저 가장 왼쪽 이벤트보다 앞서 일어나는 이벤트가 있는지 물어볼 수 있음
• Ollie와의 대화 요지: “주문서 접수됨” 이벤트는 무엇이 촉발하는가? → 매일 아침 우편물을 열어 고객이 보낸 종이 주문서를 확인하고 주문/견적으로 분류한다는 답변 → 여기서 “우편물 접수됨” 이벤트와, 이를 주문/견적으로 분류하는 워크플로우가 추가로 필요함이 드러남

콜아웃: 워크플로우, 시나리오, 유스케이스

비즈니스 활동을 가리키는 여러 용어(“workflow”, “scenario”, “use case”, “process”)는 종종 혼용되지만, 이 책에서는 다음과 같이 조금 더 정밀하게 구분해서 사용함

• Sam과의 대화 요지: 주문을 고객에게 배송한 뒤에도 이벤트가 있는가? → 주문이 “서명 후 배송 완료” 상태가 되면 택배사로부터 알림을 받는다는 답변 → “고객이 배송물에 서명함” 이벤트가 추가됨
• 이렇게 양방향으로 이벤트를 확장하는 것은 누락된 요구사항을 찾는 좋은 방법이며, 이벤트 체인은 예상보다 훨씬 길어질 수 있음

flowchart LR
    M["우편물 접수됨"] --> Q{"주문인가 견적인가?"}
    Q --> A["주문서 접수됨"]
    Q --> Q2["견적서 접수됨"]
    subgraph OT["주문접수팀 컨텍스트"]
        A --> W1[["주문하기"]]
        W1 --> B["주문 배치됨"]
        W1 --> C["확인 메일 발송됨"]
    end
    subgraph SH["배송팀 컨텍스트"]
        B --> W2[["배송하기"]]
        W2 --> D["주문 배송됨"]
        W2 --> E["발송 메시지 전달됨"]
        D --> F["고객 서명 후 배송 완료"]
    end

• 여기서 도메인 전문가는 종이 양식과 인쇄된 우편물을 이야기하고 있음에 주목할 것. 앞으로 만들 시스템은 전산화되겠지만, 종이 기반 시스템을 워크플로우/우선순위/엣지 케이스 관점에서 생각해 보는 것만으로도 많은 것을 배울 수 있음
• 실제로 많은 비즈니스 프로세스에서 종이 vs 디지털의 구분은 무관함 — 도메인의 고수준 개념을 이해하는 것은 특정 구현 방식에 전혀 의존하지 않음 (예: 회계 도메인의 개념과 용어는 수백 년간 거의 변하지 않음)
• 종이 기반 시스템을 전산화할 때도 전체를 한 번에 전환할 필요는 없음. 시스템 전체를 조망한 뒤, 가장 큰 이득을 볼 수 있는 부분부터 전환하는 것이 바람직함

1.2.4 커맨드 문서화하기

• 벽에 이런 이벤트들을 붙이고 나면 “무엇이 이 도메인 이벤트를 일으켰는가?“를 물을 수 있음 — 누군가 또는 무언가가 어떤 활동이 일어나기를 원함 (예: 고객이 주문서 접수를 원함, 상사가 어떤 일을 해달라고 요청함)
• DDD 용어로 이런 요청을 **커맨드(Command)**라 부름(객체지향 프로그래밍의 Command 패턴과 혼동하지 말 것). ==커맨드는 항상 명령형으로 작성됨== (“이것을 해줘”)
• 모든 커맨드가 성공하는 것은 아님(주문서가 우편에서 분실될 수도, 더 급한 일 때문에 상사를 도울 여유가 없을 수도 있음). 하지만 커맨드가 성공하면 워크플로우가 시작되고, 그 결과로 대응하는 도메인 이벤트가 만들어짐
• 커맨드와 이벤트의 대응 예시
  • 커맨드 “X가 일어나게 하라” → (성공 시) 이벤트 “X가 일어났다”
  • 커맨드 “Widgets Inc에 주문서를 보내라” → 이벤트 “주문서 발송됨”
  • 커맨드 “주문하기(Place an order)” → 이벤트 “주문 배치됨(Order placed)”
  • 커맨드 “고객 ABC에게 배송물을 보내라” → 이벤트 “배송물 발송됨(Shipment sent)”

// 커맨드 이름: 항상 명령형
type PlaceOrder = PlaceOrder of OrderForm

// 도메인 이벤트 이름: 항상 과거형
type OrderPlaced = OrderPlaced of Order

// 커맨드 이름: 항상 명령형
interface PlaceOrder {
  kind: "PlaceOrder";
  orderForm: OrderForm;
}

// 도메인 이벤트 이름: 항상 과거형
interface OrderPlaced {
  kind: "OrderPlaced";
  order: Order;
}

• 이 책은 대부분의 비즈니스 프로세스를 다음 패턴으로 모델링함: 이벤트가 커맨드를 촉발 → 커맨드가 비즈니스 워크플로우를 시작 → 워크플로우의 출력은 (추가) 이벤트들의 목록 → 그 이벤트들이 다시 다른 커맨드를 촉발할 수 있음

flowchart LR
    E["이벤트"] -- "triggers" --> C["커맨드"]
    C --> W[["비즈니스 워크플로우"]]
    W --> E1["이벤트"]
    W --> E2["이벤트"]
    W --> E3["이벤트"]

• 입력과 출력이 있는 파이프라인으로 비즈니스 프로세스를 생각하는 이 방식은 함수형 프로그래밍이 작동하는 방식과 매우 잘 맞음(이후 챕터들의 핵심 아이디어)
• 이 접근을 주문 접수 프로세스에 적용하면 다음과 같음: “주문서 접수됨” 이벤트가 “주문하기” 커맨드를 촉발하고, “주문 배치” 워크플로우(입력: 주문 배치에 필요한 데이터)가 실행되어, 배치된 주문으로부터 발생하는 이벤트 목록(배송용 “주문 배치됨”, 청구용 “주문 배치됨”)이 출력됨

flowchart LR
    A["주문서 접수됨"] -- "triggers" --> B["주문하기 커맨드"]
    B --> W[["주문 배치 워크플로우"]]
    W --> C["주문 배치됨 - 배송용"]
    W --> D["주문 배치됨 - 청구용"]

// 워크플로우를 "커맨드를 받아 이벤트 목록을 반환하는 함수"로 표현
type Workflow<'Command, 'Event> = 'Command -> 'Event list

type PlaceOrderWorkflow = PlaceOrder -> OrderPlaced list

// 워크플로우를 "커맨드를 받아 이벤트 목록을 반환하는 함수"로 표현
type Workflow<Command, Event> = (command: Command) => Event[];

type PlaceOrderWorkflow = (command: PlaceOrder) => OrderPlaced[];

• 지금 단계에서는 모든 커맨드가 성공하고 대응 이벤트가 발생한다고 가정함 (이후 챕터 10 “구현: 에러 다루기”에서 커맨드가 실패하는 경우를 어떻게 모델링하는지 다룸)
• 모든 이벤트가 커맨드와 연관되어야 하는 것은 아님 — 일부 이벤트는 스케줄러나 모니터링 시스템에 의해 촉발될 수 있음 (예: 회계 시스템의 월말 마감(MonthEndClose), 창고 시스템의 재고 소진(OutOfStock))

1.3 도메인을 서브도메인으로 분할하기

• 지금까지 이벤트와 커맨드 목록을 확보했고 다양한 비즈니스 프로세스에 대한 이해도 생겼지만, 전체 그림은 여전히 상당히 혼란스러움 — 코드를 작성하기 전에 이를 길들여야 함
• 두 번째 가이드라인: “문제 도메인을 더 작은 서브도메인으로 분할하라.” 큰 문제에 직면하면 별도로 다룰 수 있는 더 작은 컴포넌트로 나누는 것이 자연스러움
• 주문 접수 프로세스의 여러 측면(주문 접수, 배송, 청구 등)은 분리 가능함. 비즈니스에 이미 이런 영역에 대응하는 별도 부서가 존재한다는 사실은, 설계에서도 동일한 구분을 따를 수 있다는 강력한 힌트임 — 이런 각 영역을 **도메인(domain)**이라 부름
• “도메인”의 정의
  • 사전적 정의: “일관된 지식의 영역(an area of coherent knowledge)” — 너무 모호해서 실용적이지 않음
  • 실용적인 대안 정의: “도메인”이란 곧 “도메인 전문가”가 전문적으로 아는 것임. 예를 들어 “청구(billing)“란 청구부서 사람들(도메인 전문가들)이 하는 일이라고 말하는 것이 훨씬 편리함
• 개발자 스스로도 여러 도메인의 전문가일 수 있음 — 특정 프로그래밍 언어, 게임/과학 프로그래밍 같은 특정 분야, 보안/네트워킹/저수준 최적화 등 — 이런 것들도 모두 “도메인”임
• 도메인 안에는 구별되는 영역이 존재할 수 있으며, 이를 서브도메인(subdomain) — 자신만의 전문 지식을 가진, 더 큰 도메인의 작은 부분 — 이라 부름
  • 예: “웹 프로그래밍”은 “일반 프로그래밍”의 서브도메인이고, “자바스크립트 프로그래밍”은 웹 프로그래밍의 서브도메인(적어도 예전에는 그랬음)

flowchart TD
    subgraph GP["일반 프로그래밍"]
        subgraph WP["웹 프로그래밍"]
            JS["자바스크립트 프로그래밍"]
            CSS["CSS"]
        end
        subgraph RP["루비 프로그래밍"]
            RoR["Ruby on Rails"]
        end
    end
    WD["웹 디자인"] --- CSS

• 도메인은 서로 겹칠 수 있음: 예를 들어 “CSS” 서브도메인은 “웹 프로그래밍” 도메인의 일부로도, “웹 디자인” 도메인의 일부로도 볼 수 있음(위 다이어그램에서 CSS가 두 영역에 걸쳐 있는 것으로 표현)
• 그러므로 도메인을 더 작은 부분으로 나눌 때는 주의해야 함: 명확하고 깔끔한 경계를 원하기 쉽지만, 실세계는 그보다 훨씬 애매함(fuzzy)
• 이 도메인 분할 접근법을 주문 접수 시스템에 적용하면 다음과 같음

flowchart LR
    OT(("주문접수 도메인"))
    SH(("배송 도메인"))
    BI(("청구 도메인"))
    OT --- SH
    SH --- BI
    BI --- OT

• 세 도메인은 약간씩 겹침: 주문접수자는 청구/배송 부서가 어떻게 일하는지 조금은 알아야 하고, 배송담당자는 주문접수/청구를 조금은 알아야 하는 식
• 효과적인 솔루션을 개발하려면 개발자 스스로도 어느 정도 도메인 전문가가 되어야 함 — 즉 위 도메인들을 지금까지보다 더 깊이 이해하려는 노력이 필요함. 다만 이는 잠시 미뤄두고 다음으로 솔루션을 만드는 가이드라인으로 넘어감

1.4 바운디드 컨텍스트로 솔루션 만들기

• 문제를 이해했다고 해서 솔루션을 만드는 것이 쉬운 일은 아님. 솔루션은 원본 도메인의 모든 정보를 표현할 수 없고, 그럴 필요도 없음 — 특정 문제 해결에 관련된 정보만 포착해야 하며 나머지는 무관함
• 그래서 **“문제 공간(problem space)”**과 **“솔루션 공간(solution space)”**을 구분해야 하며, 이 둘은 서로 다른 것으로 취급되어야 함
• 솔루션을 만들기 위해서는 문제 도메인의 **모델(model)**을 만듦 — 관련 있는 측면만 추출해 솔루션 공간에서 다시 만들어냄

flowchart LR
    subgraph SPACE1["문제 공간 - 실세계"]
        direction TB
        D1(("주문접수 도메인"))
        D2(("배송 도메인"))
        D3(("청구 도메인"))
    end
    subgraph SPACE2["솔루션 공간 - 도메인 모델"]
        direction TB
        C1["주문접수 컨텍스트"]
        C2["배송 컨텍스트"]
        C3["청구 컨텍스트"]
    end
    SPACE1 -- "설계 프로세스" --> SPACE2

• 솔루션 공간에서 문제 공간의 도메인/서브도메인은 DDD 용어로 바운디드 컨텍스트(bounded context) — 구현에서의 일종의 서브시스템 — 로 매핑됨. 각 바운디드 컨텍스트는 그 자체로 하나의 미니 도메인 모델
• “서브시스템(subsystem)” 대신 “바운디드 컨텍스트”라는 표현을 쓰는 이유: 솔루션을 설계할 때 정말 중요한 것 — 컨텍스트에 대한 인식과 경계에 대한 인식 — 에 계속 초점을 맞추게 해주기 때문
  • 왜 **“컨텍스트(context)”**인가: 각 컨텍스트는 솔루션 내에서 특화된 지식을 나타내기 때문. 컨텍스트 내부에서는 공통 언어를 공유하며 설계가 일관되고 통일됨. 다만 실세계와 마찬가지로, 맥락에서 벗어난 정보는 혼란스럽거나 쓸모없어질 수 있음
  • 왜 **“경계가 있는(bounded)”**인가: 실세계에서는 도메인 경계가 애매하지만, 소프트웨어 세계에서는 별도 서브시스템들이 독립적으로 진화할 수 있도록 서로 간의 결합(coupling)을 줄이고자 함. 명시적 API를 두고 공유 코드 같은 의존성을 피하는 등 표준 소프트웨어 관행으로 이를 달성함. 그 결과 도메인 모델이 실세계만큼 풍부하지는 못하지만, 그 대가로 복잡성 감소와 유지보수 용이성을 얻음
• 문제 공간의 도메인과 솔루션 공간의 컨텍스트가 항상 1:1로 대응하는 것은 아님
  • 때로는 하나의 도메인이 여러 바운디드 컨텍스트로 나뉘기도 함
  • 더 흔하게는, 문제 공간의 여러 도메인이 솔루션 공간의 단 하나의 바운디드 컨텍스트로 모델링됨 — 특히 레거시 소프트웨어 시스템과 통합해야 할 때 흔함
  • 예: 만약 Widgets Inc가 이미 주문 접수와 청구를 하나의 시스템에서 함께 처리하는 소프트웨어 패키지를 갖고 있었다면, 이 레거시 시스템과 통합할 때는 두 도메인을 아우르더라도 이를 단일 바운디드 컨텍스트로 취급해야 할 수 있음
• 어떻게 분할하든, 각 바운디드 컨텍스트는 명확한 책임을 가져야 함 — 모델을 구현할 때 바운디드 컨텍스트는 정확히 어떤 종류의 소프트웨어 컴포넌트에 대응하게 되기 때문. 그 컴포넌트는 별도의 DLL, 독립적인 서비스, 또는 단순한 네임스페이스로 구현될 수 있음 — 구현 세부사항은 지금 중요하지 않지만, 분할을 올바르게 하는 것은 중요함

1.4.1 컨텍스트를 올바르게 설정하기

• 바운디드 컨텍스트를 정의하는 것은 말로는 쉬워 보이지만 실제로는 까다로울 수 있음. 컨텍스트 경계를 올바르게 정하는 것은 DDD의 가장 중요한 도전 중 하나이며, 이는 과학이 아니라 **예술(art, not a science)**에 가까움. 도움이 되는 가이드라인은 다음과 같음
  1. 도메인 전문가의 말을 들어라. 모두가 같은 언어를 공유하고 같은 이슈에 집중한다면, 그들은 아마 같은 서브도메인(하나의 바운디드 컨텍스트에 대응)에서 일하고 있는 것
  2. 기존 팀/부서 경계에 주의를 기울여라. 이는 비즈니스가 무엇을 도메인/서브도메인으로 여기는지에 대한 강력한 단서. 다만 항상 참은 아님 — 같은 부서 사람들이 서로 다른 방향으로 일할 수도 있고, 반대로 다른 부서 사람들이 매우 긴밀히 협업하여 사실상 같은 도메인에서 일하고 있는 것일 수도 있음
  3. 바운디드 컨텍스트의 “경계가 있는(bounded)” 부분을 잊지 마라. 경계를 설정할 때 스코프 크리프(scope creep)를 경계해야 함. 요구사항이 계속 바뀌는 복잡한 프로젝트에서는 “경계가 있는” 부분을 지키는 데 단호해야 함. 너무 크거나 모호한 경계는 경계가 아닌 것과 마찬가지 — “좋은 담장이 좋은 이웃을 만든다”
  4. 자율성을 위해 설계하라. 두 그룹이 같은 바운디드 컨텍스트에 함께 기여하면, 설계가 진화하면서 서로 다른 방향으로 끌려갈 수 있음. 다리를 서로 묶은 2인3각 경주에 비유할 수 있음: 묶인 두 주자는 자유롭게 뛰는 두 주자보다 항상 느림. 도메인 모델도 마찬가지 — 모두를 만족시키려는 하나의 거대 컨텍스트보다, 독립적으로 진화할 수 있는 분리된 자율적 바운디드 컨텍스트를 갖는 것이 항상 더 나음
  5. 마찰 없는 비즈니스 워크플로우를 위해 설계하라. 어떤 워크플로우가 여러 바운디드 컨텍스트와 상호작용하면서 자주 막히거나 지연된다면, 설계가 “덜 예뻐지더라도(uglier)” 워크플로우를 매끄럽게 만들도록 컨텍스트를 리팩터링하는 것을 고려해야 함. 즉, “순수한(pure)” 설계보다 항상 비즈니스와 고객 가치를 우선해야 함
• 어떤 설계도 정적이지 않으며, 비즈니스 요구사항이 변함에 따라 모델도 진화해야 함(챕터 13 “설계를 진화시키고 깔끔하게 유지하기”에서 자세히 다룸)

1.4.2 컨텍스트 맵 만들기

• 컨텍스트들을 정의한 후에는, 설계 세부사항에 매몰되지 않으면서 그들 사이의 상호작용(큰 그림)을 전달할 방법이 필요함 — DDD 용어로 이 다이어그램을 **컨텍스트 맵(Context Map)**이라 부름
• 여행용 노선도(route map)에 비유할 수 있음: 노선도는 모든 세부사항을 보여주지 않고, 여정을 계획할 수 있도록 주요 노선만 보여줌

flowchart LR
    Boston(("보스턴")) -- "United" --> London(("런던"))
    London -- "United" --> Boston
    Boston -- "Delta" --> Chicago(("시카고"))
    NewYork(("뉴욕")) -- "Lufthansa" --> London
    NewYork -- "United" --> Chicago
    Paris(("파리")) -- "Air France" --> Chicago

• 이 다이어그램은 각 도시의 세부사항을 보여주지 않고, 도시 간 이용 가능한 노선만 보여줌. 지도의 유일한 목적은 항공편 계획을 돕는 것 — 뉴욕 시내에서 운전하는 것처럼 다른 무언가를 하고 싶다면 다른 지도(그리고 혈압약)가 필요할 것
• 같은 방식으로, 컨텍스트 맵은 다양한 바운디드 컨텍스트와 그들 사이의 관계를 고수준으로 보여줌. 모든 세부사항을 포착하는 것이 아니라 시스템 전체에 대한 관점을 제공하는 것이 목표

flowchart TD
    Cust(("고객")) -- "주문/견적 접수" --> OTC["주문접수 컨텍스트"]
    OTC -- "견적 반환" --> Cust
    OTC -- "주문 배치됨" --> SHC["배송 컨텍스트"]
    OTC -- "주문 배치됨" --> BIC["청구 컨텍스트"]

• 이 맵을 만들 때는 배송 컨텍스트의 내부 구조에는 관심이 없음 — 배송 컨텍스트가 주문접수 컨텍스트로부터 데이터를 받는다는 사실만 중요함. 이를 비공식적으로 배송 컨텍스트는 다운스트림(downstream), 주문접수 컨텍스트는 **업스트림(upstream)**이라고 표현함
• 두 컨텍스트는 교환하는 메시지에 대해 공유 포맷을 합의해야 함. 일반적으로 업스트림 컨텍스트가 포맷에 대해 더 많은 영향력을 갖지만, 때로는(레거시 시스템 작업 등) 다운스트림 컨텍스트가 유연하지 않을 수 있음 — 이 경우 업스트림 컨텍스트가 적응하거나, 중개자 역할을 하는 번역(translator) 컴포넌트가 필요할 수 있음(이는 이후 챕터의 “바운디드 컨텍스트 간의 계약”에서 더 자세히 다룸)
• 지금까지의 설계는 하나의 맵에 다 담을 수 있지만, 더 복잡한 설계에서는 특정 서브시스템에 초점을 맞춘 여러 개의 작은 맵을 만드는 것이 자연스러움

1.4.3 가장 중요한 바운디드 컨텍스트에 집중하기

• 지금까지 몇 개의 명백한 바운디드 컨텍스트를 확보했고, 도메인을 더 다루다 보면 더 많이 발견하게 될 것. 하지만 이들이 모두 동등하게 중요한가? 개발을 시작할 때 어디에 집중해야 하는가?
• 일반적으로 어떤 도메인은 다른 도메인보다 더 중요함

• 다만 현실은 언제나 이렇게 단순하지 않음. 예를 들어 어떤 이커머스 비즈니스는 재고 보유와 즉시 배송 가능 여부가 고객 만족에 결정적이라고 판단해, 재고 관리를 사용하기 쉬운 웹사이트만큼이나 비즈니스 성공에 핵심적인 도메인으로 삼을 수 있음
• 때로는 어떤 도메인이 가장 중요한지에 대한 합의가 없을 수도 있음 — 각 부서는 자기 도메인이 가장 중요하다고 생각하는 경향이 있음. 그리고 때로는, 핵심 도메인은 단순히 클라이언트가 작업해달라고 요청하는 대상일 뿐일 수도 있음
• 어떤 경우든 우선순위를 정하고, 모든 바운디드 컨텍스트를 동시에 구현하려 시도하지 않는 것이 중요함 — 그런 시도는 실패로 이어지는 경우가 많음. 가장 큰 가치를 더하는 바운디드 컨텍스트에 먼저 집중한 다음, 거기서부터 확장해 나가야 함

1.5 유비쿼터스 언어 만들기

• 앞서 코드와 도메인 전문가가 동일한 모델을 공유해야 한다고 강조했음. 즉 설계 안의 요소들은 도메인 전문가의 멘탈 모델 속 실제 대상을 표현해야 함. 도메인 전문가가 무언가를 “주문(order)“이라 부른다면, 코드에도 이에 대응하고 동일하게 동작하는 Order가 있어야 함
• 반대로, 설계에는 도메인 전문가의 모델에 없는 요소가 있어서는 안 됨 — 즉 OrderFactory, OrderManager, OrderHelper 같은 용어는 지양해야 함. 도메인 전문가는 이런 단어의 의미를 모름. 물론 일부 기술 용어는 코드베이스에 등장할 수밖에 없지만, 이를 설계의 일부로 노출하는 것은 피해야 함

// 지양: 도메인 전문가가 모르는 기술 용어를 설계에 노출
module OrderManager =
    let processOrder (helper: OrderHelper) (order: Order) =
        helper.Validate(order)

// 지향: 유비쿼터스 언어(도메인 전문가가 실제로 쓰는 말)를 그대로 반영
module OrderTaking =
    let placeOrder (unvalidatedOrder: UnvalidatedOrder) : PlaceOrderEvents =
        // ...
        failwith "구현 예시"

// 지양: 도메인 전문가가 모르는 기술 용어를 설계에 노출
class OrderManager {
  constructor(private helper: OrderHelper) {}
  processOrder(order: Order) {
    return this.helper.validate(order);
  }
}

// 지향: 유비쿼터스 언어(도메인 전문가가 실제로 쓰는 말)를 그대로 반영
function placeOrder(unvalidatedOrder: UnvalidatedOrder): PlaceOrderEvents {
  // ...
  throw new Error("구현 예시");
}

• 팀 전체가 공유하는 개념과 어휘의 집합을 유비쿼터스 언어(Ubiquitous Language) — “어디에나 있는 언어” — 라 부름. 이는 비즈니스 도메인에 대한 공유된 멘탈 모델을 정의하는 언어이며, 이름 그대로 요구사항뿐 아니라 설계, 그리고 무엇보다 소스 코드에서 프로젝트 전반에 걸쳐 사용되어야 함
• 유비쿼터스 언어의 구축은 도메인 전문가가 일방적으로 지시하는 프로세스가 아니라 팀 전체의 협업임. 또한 이 언어가 정적일 것이라 기대해서는 안 됨 — 언제나 진행 중인 작업(work in progress)임. 설계가 진화함에 따라 새로운 용어와 개념을 발견할 준비가 되어 있어야 하고, 유비쿼터스 언어도 그에 맞게 함께 진화시켜야 함
• 중요한 점: 모든 도메인과 컨텍스트를 아우르는 단 하나의 유비쿼터스 언어를 가질 수 없는 경우가 많음. 각 컨텍스트는 유비쿼터스 언어의 **“방언(dialect)”**을 가지며, 같은 단어가 다른 방언에서는 다른 것을 의미할 수 있음
  • 예: “class”는 객체지향 프로그래밍 도메인과 CSS 도메인에서 전혀 다른 것을 의미함
  • “Customer”나 “Product” 같은 단어를 여러 컨텍스트에서 동일한 의미로 만들려는 시도는, 잘해야 복잡한 요구사항을, 최악의 경우 심각한 설계 오류를 낳을 수 있음
• 이벤트 스토밍 세션에서도 이 문제가 그대로 드러남: 모든 참가자가 “order”라는 단어를 사용했지만, 배송부서의 “order” 정의와 청구부서의 정의는 미묘하게 다를 수 있음. 배송부서는 재고 수준, 아이템 수량 등에 관심이 있고, 청구부서는 가격과 금액에 더 관심이 있음. 컨텍스트를 명시하지 않고 어디서나 “order”라는 같은 단어를 쓰면 고통스러운 오해를 겪을 수 있음

1.6 도메인 주도 설계 개념 요약하기

• 새로운 개념과 용어가 많이 등장했으므로, 다음 단계로 넘어가기 전에 한 곳에 요약함

1.7 마무리하기

• 챕터 도입부에서 개발팀과 도메인 전문가 모두에게 동일한, 공유된 도메인/솔루션 모델을 만드는 것의 중요성을 강조했음
• 이를 위한 4가지 가이드라인을 논의함
  1. 데이터보다 이벤트와 프로세스에 집중한다
  2. 문제 도메인을 더 작은 서브도메인으로 분할한다
  3. 솔루션에서 각 서브도메인의 모델을 생성한다
  4. 관련된 모든 사람이 공유할 수 있는 “어디에나 있는 언어”를 개발한다
• 이를 주문 접수 도메인에 어떻게 적용했는지 정리하면 다음과 같음

1.7.1 이벤트와 프로세스

• 이벤트 스토밍 세션은 도메인의 주요 도메인 이벤트를 빠르게 드러냄
• 주문 접수 프로세스는 우편으로 주문서를 받는 것에서 촉발되며, 견적 처리, 신규 고객 등록 등을 위한 워크플로우가 존재한다는 것을 학습함
• 또한 주문접수팀이 주문 처리를 마치면 그 이벤트가 배송부서의 배송 프로세스와 청구부서의 청구 프로세스를 촉발한다는 것을 학습함

1.7.2 서브도메인과 바운디드 컨텍스트

• 지금까지 “주문 접수(Order Taking)”, “배송(Shipping)”, “청구(Billing)” 세 서브도메인을 발견한 것으로 보임
• “도메인이란 도메인 전문가가 전문적으로 아는 것”이라는 규칙으로 이를 확인함: Ollie에게 청구 프로세스를 아느냐고 물었을 때, Ollie는 조금은 알지만 자세한 내용은 청구팀에 직접 물어봐야 한다고 답함 → 청구가 별도의 도메인임이 확인됨
• 이 세 서브도메인에 대응하는 세 개의 바운디드 컨텍스트를 정의하고, 이들의 상호작용을 보여주는 컨텍스트 맵을 작성함
• 어느 것이 우리가 집중해야 할 핵심 도메인인지는 원래 매니저 Max와 상의해 자동화가 가장 큰 가치를 더할 곳을 결정해야 하지만, 지금은 주문 접수 도메인을 먼저 구현한다고 가정함. 필요하다면 이 도메인의 산출물을 종이 문서로 변환해, 다른 팀들이 기존 프로세스를 중단 없이 계속할 수 있게 할 수 있음

1.7.3 유비쿼터스 언어

• 지금까지 “주문서(order form)”, “견적(quote)”, “주문(order)” 같은 용어를 확보했으며, 설계를 더 파고들수록 더 많은 용어를 발견하게 될 것
• 공유된 이해를 유지하기 위해, 이런 용어와 정의를 나열한 살아있는 문서나 위키 페이지를 만드는 것이 좋은 방법임 — 팀 전체의 정렬을 유지하고 신규 팀원의 온보딩 속도를 높이는 데 도움이 됨

1.7.4 다음은 무엇인가?

• 문제에 대한 개요와 솔루션의 개략적인 윤곽은 확보했지만, 저수준 설계나 코딩을 시작하기 전에 답해야 할 질문이 아직 많이 남아 있음
• 예: 주문 처리 워크플로우에서 정확히 무슨 일이 일어나는가? 입력과 출력은 무엇인가? 이 워크플로우가 상호작용하는 다른 컨텍스트가 있는가? 배송팀의 “주문” 개념은 청구팀의 것과 어떻게 다른가?
• 다음 챕터에서는 주문 배치(order-placing) 워크플로우를 깊이 파고들어 이런 질문들에 답한다

챕터 2 도메인 이해하기

• 1장 요약: 도메인 전체 그림(overview)과 핵심 비즈니스 이벤트를 파악하고, 솔루션 공간을 여러 바운디드 컨텍스트(bounded context) 로 분할함. 도메인 주도 설계(DDD)와 공유 모델(shared model)의 중요성을 학습함
• 이 장의 목표: 하나의 특정 워크플로우(주문 접수)를 선택해 깊이 있게 이해하기
  • 무엇이 이 워크플로우를 트리거하는가
  • 어떤 데이터가 필요한가
  • 다른 바운디드 컨텍스트와 어떻게 협업하는가
• 핵심 스킬: ==경청(careful listening)== — 자신의 정신 모델(mental model)을 도메인에 강요하지 않는 것이 중요함

2.1 도메인 전문가 인터뷰하기

• 깊은 이해를 얻기 위해 도메인 전문가와 심층 인터뷰를 진행함
  • 인터뷰 대상: Ollie (주문 접수 부서 소속 도메인 전문가)
• 도메인 전문가는 대체로 바쁘고 개발자와 오래 시간을 보내기 어려움
  • 커맨드/이벤트(commands/events) 접근법의 장점: 하루 종일 걸리는 회의 대신, 하나의 워크플로우에만 집중하는 짧은 인터뷰를 여러 번 진행할 수 있어 도메인 전문가가 시간을 내기 쉬움
• 인터뷰 전반부 전략: 높은 수준(high level)을 유지하며 워크플로우의 입력과 출력에만 집중
  • 아직 관련 없는 세부 사항에 매몰되는 것을 방지하기 위함

인터뷰 시작

• 질문: 주문 접수(order-placing) 프로세스를 시작하려면 어떤 정보가 필요한가
• Ollie 답변 요약
  • 고객이 작성해서 우편으로 보내는 종이 주문서(order form)에서 모든 것이 시작됨
  • 전산화 버전에서는 고객이 이 양식을 온라인으로 작성하길 원함

주문서(Order Form) 구조

초기 가정과 정정

• 인터뷰어는 처음에 전형적인 이커머스 모델(제품 페이지 탐색 → 장바구니 담기 → 체크아웃)을 가정함
• Ollie가 정정
  • 고객은 이미 원하는 상품을 정확히 알고 있음
  • 제품 코드와 수량만 입력하는 단순한 양식을 원함
  • 한 번에 200~300개 품목을 주문하기도 하므로, 제품 페이지를 일일이 클릭하는 방식은 지나치게 느림

핵심 교훈: 도메인을 배우는 입장이므로 (이 경우처럼) 고객이 시스템을 어떻게 사용할지 등 어떤 것에 대해서도 성급하게 결론을 내리려는 충동을 억제해야 함. 좋은 인터뷰란 곧 많이 듣는 것(listening)임. 도메인을 배우는 가장 좋은 방법은 인류학자(anthropologist)처럼 선입견 없이 접근하는 것. 이상적으로는 설계를 확정하기 전에 현장 관찰, 사용성 테스트 등 심층 리서치를 수행해야 하지만, 이 사례에서는 Ollie가 고객의 니즈를 충분히 대변할 수 있다고 신뢰하고 그 단계를 생략함

2.1.1 비기능적 요구사항 이해하기

• 워크플로우의 맥락(context)과 규모(scale)를 파악하는 단계
• 고객 특성
  • B2B(기업 간 거래) 회사이며 고객은 다른 기업들임
  • 고객사 수: 약 1,000곳
  • 주문 빈도: 고객사당 보통 주 1회 주문
  • 일 평균 주문량: 약 200건/영업일
  • 연중 물량이 일정함 (연휴 등 특수 성수기에 급증하지 않음)
  • → 설계 시 대규모 트래픽이나 스파이크성 트래픽에 대비할 필요가 없음
• 사용자(고객) 숙련도
  • 고객은 구매 업무를 전업으로 하는 전문가(expert) 임
  • 원하는 바를 정확히 알고 있으며, 효율적인 처리 방법만 필요로 함
  • → 초보자용 시스템과 달리 전문가의 작업을 방해하는 장벽을 최소화해야 함
• 응답 속도(latency) 요구사항
  • 영업일 종료 전까지 확인(acknowledgment)을 받아야 함
  • 이 비즈니스에서는 속도보다 일관성(예측 가능성) 이 더 중요함
  • 고객은 회사가 예측 가능한 방식으로 응답하고 배송할 것이라는 신뢰를 원함
• 시사점: 전형적인 B2B 애플리케이션 요구사항
  • 예측 가능성(predictability)
  • 견고한 데이터 처리(robust data handling)
  • 분쟁 발생 시를 대비한 감사 추적(audit trail)

2.1.2 작업 흐름의 나머지 부분 이해하기

• Ollie가 각 주문서를 처리하는 절차
  1. 제품 코드가 올바른지 확인 (오타나 존재하지 않는 상품이 있을 수 있음)
  2. 제품 카탈로그(매월 발행되는 리플렛)에서 코드를 조회하여 존재 여부 확인
     • 제품 카탈로그는 별도의 바운디드 컨텍스트일 가능성이 높음 → 나중에 자세히 다루기로 하고, 지금은 이 워크플로우가 그 컨텍스트로부터 필요로 하는 것(제품 목록과 가격)만 기록해 둠
  3. 품목별 비용을 합산해 Total 필드에 기입
  4. 사본 2부를 만들어 배송 부서(shipping)와 청구 부서(billing)에 각각 전달, 원본은 자체 보관
  5. 원본을 스캔하여 표준 확인서(acknowledgment letter)와 함께 이메일로 고객에게 발송 (이를 “주문 확인서”라고 부름)
• 주문서의 Order / Quote 체크박스
  • Order 체크 → 주문(order)
  • Quote 체크 → 견적(quote)
  • Quote(견적): 고객이 가격 계산만 원할 뿐 실제 배송을 원하지 않는 경우
    • 가격을 기입해 고객에게 회신만 함
    • 배송/청구 부서에는 사본을 보내지 않음 (그들이 할 일이 없기 때문)
  • 시사점: Order와 Quote는 같은 양식을 사용할 만큼 유사하지만, 이후의 워크플로우는 서로 다름

2.1.3 입력 생각해보기

• 지금까지 파악한 워크플로우의 입력/출력을 정리
• 입력: 주문서(order form) — 정확한 정의는 추후 구체화 필요
• 출력: 명확하지 않았던 부분
  • “완료된 주문(completed order)”(검증되고 가격이 매겨진 상태)은 출력이 될 수 없음 — 그 자체로 직접 사용되는 대상이 아니기 때문
  • “주문 확인서(order acknowledgment)” 역시 출력이 아님 — 확인서 발송은 워크플로우의 부수 효과(side effect) 일 뿐, 출력 자체가 아님
• ==핵심 원칙: 워크플로우의 출력은 항상 그 워크플로우가 생성하는 이벤트여야 함== — 다른 바운디드 컨텍스트에서 동작을 트리거하는 대상
  • 이 사례의 출력: OrderPlaced 이벤트 → 배송(Shipping) 및 청구(Billing) 컨텍스트로 전달됨
  • 이벤트가 실제로 각 부서에 어떻게 전달되는지는 나중에 논의할 사항이며, 지금 설계와는 무관함

Place Order 워크플로우의 입력/출력 다이어그램

flowchart LR
    IN1["입력: 주문서"] --> WF["워크플로우: Place Order"]
    IN2["추가 입력: 제품 카탈로그"] --> WF
    WF --> OUT1["출력: OrderPlaced 이벤트<br/>(배송/청구 컨텍스트에 통지)"]
    WF --> OUT2["부수 효과: 고객에게<br/>주문 확인서 전송"]

2.2 데이터베이스 중심 디자인 지양하기

• 대부분의 개발자는 이 시점에서 곧바로 저수준 설계/구현을 스케치하고 싶은 충동을 느낌
• 주문서를 보면 고객 정보, 여러 주소, 주문 라인 목록 등으로 구성되어 있음을 알 수 있음
• 데이터베이스 경험이 많은 개발자의 첫 본능: 테이블과 그 관계를 떠올림
  • Order 테이블, OrderLine 테이블, Customer/Address/Product 테이블과 그 관계(FK)를 스케치

erDiagram
    CUSTOMER ||--o{ ORDER_TABLE : "n..1"
    ADDRESS ||--o{ ORDER_TABLE : "n..1 (배송주소)"
    ADDRESS ||--o{ ORDER_TABLE : "n..1 (청구주소)"
    ORDER_TABLE ||--o{ ORDER_LINE : "1..n"
    PRODUCT ||--o{ ORDER_LINE : "n..1"

    ORDER_TABLE {
        int CustomerId
        int ShippingAddressId
        int BillingAddressId
        bool IsQuote
    }
    ORDER_LINE {
        int OrderId
        int ProductId
        int Quantity
    }

• ==이렇게 하면 실수하는 것== — DDD에서는 데이터베이스 스키마가 아니라 도메인이 설계를 주도해야 함
• 저장소(storage) 구현과 무관하게 도메인으로부터 모델링을 시작하는 것이 바람직함
  • 실제 종이 기반 시스템에는 “데이터베이스”라는 개념 자체가 없음
  • “데이터베이스”는 유비쿼터스 언어(ubiquitous language)에 속하지 않음
  • 사용자는 데이터가 어떻게 저장되는지 신경 쓰지 않음
• 이 원칙을 DDD 용어로 퍼시스턴스 무관성(persistence ignorance) 이라 부름
  • 데이터베이스 표현을 걱정하지 않고 도메인을 정확히 모델링하는 데 집중하도록 강제하는 중요한 원칙
• 데이터베이스 관점으로 설계할 때의 문제: 데이터베이스 모델에 맞추기 위해 설계가 왜곡되는 경우가 많음
• 왜곡의 예시: 위 다이어그램에서는 Order와 Quote의 차이를 IsQuote 플래그 하나로만 뭉뚱그림
  • 실제로는 비즈니스 규칙과 검증 규칙이 서로 다름 (예: Order는 반드시 청구 주소가 있어야 하지만 Quote는 없어도 될 수 있음)
  • 이런 미묘한 차이는 외래 키(foreign key) 하나로 표현하기 어려움 — 같은 외래 키가 두 가지 다른 관계를 동시에 담당하면서 이 구분이 사라져 버림
  • 나중에 영속성(persistence)을 다루는 장에서 관계형 데이터베이스에 도메인 모델을 저장하는 방법을 다시 살펴볼 예정이나, 지금은 선입견 없이 요구사항을 경청하는 데 집중해야 함

데이터베이스 스키마 관점 예시 (지양해야 할 설계)

// 지양해야 할 설계 예시 (데이터베이스 스키마 중심 사고의 함정)
interface OrderTableRow {
  customerId: number;
  shippingAddressId: number;
  billingAddressId: number;
  isQuote: boolean; // Order와 Quote의 차이를 단순 플래그로 뭉뚱그림 -> 비즈니스 규칙 표현의 한계
}

interface OrderLineTableRow {
  orderId: number;
  productId: number;
  quantity: number;
}

2.3 클래스 중심 디자인 지양하기

• 객체지향(OO) 경험이 많은 개발자는 이미 데이터베이스 구현과 비즈니스 로직을 분리하는 데(예: 의존성 주입) 익숙할 수 있음
• 하지만 데이터베이스 대신 “객체” 관점으로 사고하면서 또 다른 편향을 설계에 끌어들일 수 있음
• 예시: Ollie와 대화하는 동안 머릿속으로 클래스를 구상하게 되는 경우
  • Order와 Quote를 분리했지만, 실제 도메인에는 존재하지 않는 인위적인 기반 클래스 OrderBase를 도입 → 도메인의 왜곡

classDiagram
    class OrderBase {
        Customer customer
    }
    class Order {
        Address shippingAddress
        Address billingAddress
    }
    class Quote
    class OrderLine {
        int quantity
    }
    class Customer
    class Address
    class Product

    OrderBase <|-- Order
    OrderBase <|-- Quote
    OrderBase --> Customer : n..1
    Order --> Address : 배송주소 n..1
    Order --> Address : 청구주소 n..1
    OrderBase "1" --> "1..n" OrderLine : 포함
    OrderLine --> Product : n..1

• ==클래스가 설계를 주도하게 두는 것은 데이터베이스가 설계를 주도하게 두는 것만큼 위험함== — 이 역시 요구사항을 제대로 경청하지 않은 것
• 도메인 전문가에게 “OrderBase가 무엇인가요?“라고 직접 물어보면, 그런 개념은 실제 업무에 존재하지 않는다는 것을 알 수 있음
• 교훈: 요구사항을 수집하는 동안에는 마음을 열어두고, 자신의 기술적 아이디어를 도메인에 강요하지 말아야 함

클래스 중심 사고의 함정 예시 (지양해야 할 설계)

// 지양해야 할 설계 예시 (클래스 중심 사고의 함정)
// OrderBase는 실제 도메인 전문가의 언어에는 존재하지 않는 인위적인 개념임
abstract class OrderBase {
  constructor(public customer: Customer) {}
}

class Order extends OrderBase {
  constructor(
    customer: Customer,
    public shippingAddress: Address,
    public billingAddress: Address,
    public orderLines: OrderLine[]
  ) {
    super(customer);
  }
}

class Quote extends OrderBase {
  constructor(
    customer: Customer,
    public shippingAddress: Address,
    public billingAddress: Address
  ) {
    super(customer);
  }
}

class OrderLine {
  constructor(public product: Product, public quantity: number) {}
}

2.4 도메인 문서화

• 질문: 기술적 편향(DB, 클래스)을 피하면서 요구사항을 어떻게 기록할 것인가
• 시각적 다이어그램(예: UML) 사용 가능하지만, 다루기 번거롭고 도메인의 미묘한 부분을 담기엔 세밀함이 부족한 경우가 많음
• 책의 후반부에서는 F# 타입 시스템으로 정확한 도메인 모델을 코드로 만드는 방법을 다룰 예정
• 지금 단계에서는 도메인 모델을 담아낼 간단한 텍스트 기반 미니 언어를 만들어 사용함
  • 워크플로우: 입력과 출력을 문서화하고, 비즈니스 로직은 간단한 의사코드(pseudocode)로 표현
  • 데이터 구조: AND는 두 부분이 모두 필요함을 의미 (예: Name AND Address), OR는 둘 중 하나만 있으면 됨을 의미 (예: Email OR PhoneNumber)

Place Order 워크플로우 문서화 예시

Bounded context: Order-Taking

Workflow: "Place order"
triggered by:
  "Order form received" event (when Quote is not checked)
primary input:
  An order form
other input:
  Product catalog
output events:
  "Order Placed" event
side-effects:
  An acknowledgment is sent to the customer,
  along with the placed order

// bounded context: Order-Taking

/**
 * workflow: "Place order"
 * trigger: "OrderFormReceived" 이벤트 (Quote 체크박스가 선택되지 않았을 때)
 * primary input: OrderForm
 * other input: ProductCatalog
 * output events: OrderPlaced
 * side-effects: 고객에게 주문 확인서(acknowledgment)와 접수된 주문을 함께 전송
 */
interface PlaceOrderWorkflowSpec {
  trigger: "OrderFormReceived";
  primaryInput: OrderForm;
  otherInput: ProductCatalog;
  outputEvents: OrderPlaced;
  sideEffects: "고객에게 주문 확인서 전송";
}

데이터 구조 문서화 예시

bounded context: Order-Taking

data Order =
  CustomerInfo
  AND ShippingAddress
  AND BillingAddress
  AND list of OrderLines
  AND AmountToBill

data OrderLine =
  Product
  AND Quantity
  AND Price

data CustomerInfo = ??? // don't know yet
data BillingAddress = ??? // don't know yet

// bounded context: Order-Taking

interface Order {
  customerInfo: CustomerInfo;
  shippingAddress: ShippingAddress;
  billingAddress: BillingAddress;
  orderLines: OrderLine[];
  amountToBill: AmountToBill;
}

interface OrderLine {
  product: Product;
  quantity: Quantity;
  price: Price;
}

// 아직 정의되지 않음 (원서에서는 ??? 로 표기)
type CustomerInfo = unknown;
type BillingAddress = unknown;

• Provide Quote 워크플로우와 관련 데이터 구조도 동일한 방식으로 문서화 가능 (본문에서는 상세 생략)
• 이 단계에서는 클래스 계층이나 데이터베이스 테이블을 전혀 만들지 않고, 도메인을 구조화된 방식으로만 담아냄
• 텍스트 기반 설계의 장점: 비개발자에게도 낯설지 않아 도메인 전문가에게 직접 보여주고 함께 작업할 수 있음
• 남은 질문: 실제 코드도 이만큼 단순하게 만들 수 있을까 → 이후 “타입을 이용한 도메인 모델링” 장에서 시도

2.5 주문 접수 작업 흐름을 깊이 파고들기

• 입력/출력 문서화가 끝났으니 이제 주문 접수 워크플로우를 상세히 이해할 차례

우편물 분류 및 우선순위

• 아침에 우편물이 도착하면 Ollie가 가장 먼저 분류 작업을 함
  • 주문서는 한 더미(pile), 다른 서신은 다른 더미로 분류
  • 각 양식에서 Quote 체크박스가 선택되어 있으면 “나중에 처리할 견적 더미”에 올려둠
• 이유: 주문(order)이 항상 더 중요함 — 회사는 주문으로 돈을 벌고, 견적으로는 돈을 벌지 않음
  • ==핵심 통찰: 개발자는 기술적 관점에서 모든 요구사항을 동등하게 취급하는 경향이 있지만, 비즈니스는 그렇지 않음. 돈을 벌거나 절약하는 것이 거의 항상 개발 프로젝트의 핵심 동인이므로, 우선순위가 불분명할 때는 “돈을 따라가라(follow the money)”==
  • 설계 시 (돈을 버는) 주문을 견적보다 우선 처리하도록 해야 함

주소 및 고객 정보 검증

• 주문서 처리의 첫 단계: 고객 이름, 이메일, 배송 주소, 청구 주소의 유효성 확인
• 주소 확인은 Ollie 컴퓨터의 전용 애플리케이션으로 수행
  • 주소를 입력하면 존재 여부를 확인하고, 배송업체가 요구하는 표준 형식으로 정리해 줌
  • → 워크플로우가 컨텍스트 외부의 서드파티 주소 확인 서비스와 통신해야 한다는 새로운 사실 발견
  • 이 부분은 이전 이벤트 스토밍(Event Storming) 단계에서 놓쳤던 내용이므로 별도로 기록해 두어야 함
• 이름/주소가 유효하지 않으면 빨간 펜으로 문제를 표시하고 “유효하지 않은 양식” 더미에 올려둠 → 이후 고객에게 전화해 정보를 정정 요청
• 이 시점까지 파악된 세 가지 더미
  1. 새로 도착한 주문서 (우편함에서)
  2. 나중에 처리할 견적 더미
  3. 나중에 처리할 유효하지 않은 주문서 더미
• ==통찰: “종이 더미(pile)“는 대부분의 비즈니스 프로세스에서 매우 중요한 요소이며, 더미마다 중요도가 다르다는 점을 설계에 반드시 반영해야 함. 구현 단계에서는 “종이 더미”가 큐(queue)에 잘 대응되지만, 지금은 기술적 세부 사항에서 벗어나 있어야 함==

제품 코드 검증

• 제품 코드도 형식이 명백히 잘못된 경우가 있음
  • Widget 코드: W로 시작 + 숫자 4자리
  • Gizmo 코드: G로 시작 + 숫자 3자리
  • 다른 유형의 제품 코드는 없으며, 앞으로도 바뀔 가능성이 낮음 (수년간 형식이 변경되지 않음)
• 제품 코드 검증은 두 단계로 구성됨
  1. 형식(syntax) 검사: W 또는 G로 시작하는지 등 순수하게 문법적인 검사 — 제품 카탈로그 조회가 필요 없음
  2. 존재(existence) 검사: 제품 카탈로그(Ollie에게는 책자, 소프트웨어라면 데이터베이스 조회)에서 실제로 존재하는 코드인지 확인
     • 존재하지 않으면 오류를 표시하고 유효하지 않은 주문 더미에 올려둠

의존성 관리와 자율성

• 질문: 제품팀이 모든 문의에 즉시 응답할 수 있다면 Ollie는 여전히 자신만의 제품 카탈로그 사본이 필요할까
• Ollie의 답변 요지: 속도의 문제가 아니라 통제(control)의 문제
  • 제품팀이 바쁘거나 전화가 안 될 수도 있으므로, 자신만의 카탈로그가 있으면 다른 부서의 가용성에 의존하지 않고 거의 모든 주문서를 처리할 수 있음
• ==시사점: 이는 성능이 아니라 의존성 관리(dependency management)의 문제이며, 앞서 다룬 바운디드 컨텍스트의 자율성(autonomy)과 연결됨. 도메인 모델에 직접 반영할지는 상황에 따라 다르지만, 각 부서가 독립적으로 일할 수 있어야 한다는 요구사항은 반드시 인지하고 있어야 함==

수량 검증과 유비쿼터스 언어

• 질문: 주문 수량은 정수(integer)인가 소수(float)인가
  • Ollie는 “float”이라는 프로그래밍 용어를 이해하지 못함 (물처럼 뜨는 것이냐고 반문)
  • ==교훈: 유비쿼터스 언어(ubiquitous language) — 도메인 전문가는 “float” 같은 프로그래밍 용어를 사용하지 않음. Ollie는 이를 “주문 수량(order quantity)“이라고 부름 → OrderQuantity, ProductCode, AmountToBill 등이 유비쿼터스 언어의 단어가 됨==
• 다시 질문: 주문 수량에 소수점이 있는가, 아니면 정수만 가능한가
  • 답변: “상황에 따라 다름(it depends)”
    • Widget: 개당(unit) 판매 → 정수만 가능 (예: 1.5개는 실수)
    • Gizmo: 킬로그램 단위 판매 → 소수 허용

가격 책정 및 마무리 처리

• 제품 코드와 수량이 모두 유효하면
  1. 각 라인의 가격을 기입하고 합산하여 총 청구 금액(amount to bill) 계산
  2. 사본 2부 작성: 원본은 파일 보관, 사본 1부는 배송 부서 발신함, 사본 1부는 청구 부서 발신함
  3. 원본을 스캔하여 표준 확인서와 함께 이메일로 고객에게 발송
• 처리 단계 구분 방법 (양식이 섞이지 않도록)
  • 검증이 끝난 양식은 모서리에 표시를 남김
  • 가격 책정이 끝났는지는 “Total” 칸이 채워져 있는지로 구분 가능
  • → 각 처리 단계마다 표시를 남겨 서로 다른 단계의 양식을 항상 구분할 수 있음

2.6 복잡미묘한 도메인 모델링하기

• 워크플로우를 깊이 파고들수록 도메인 모델이 더 복잡해짐 — 이는 좋은 신호임
• 코딩 중반에 복잡성을 마주하기보다, 지금 미리 이해해 두는 편이 훨씬 나음
  • 흔한 격언(“계획에 한 시간을 쓰면 프로그래밍 몇 주를 절약한다”)을 역설적으로 비틀어, 지금 설계에 충분히 시간을 들이는 것의 가치를 강조함
• 현재까지 파악된 워크플로우 다이어그램

flowchart TD
    MAIL["미분류 우편물"] --> UO["미검증 주문서"]
    MAIL --> UQ["미검증 견적서"]
    UQ --> OTHER["다른 워크플로우로"]
    UO --> VAL["검증 Validation"]
    ACS["주소 확인 서비스"] --> VAL
    CAT["제품 카탈로그"] -- "제품 코드 확인" --> VAL
    VAL --> VORDER["검증된 주문"]
    VORDER --> PRICE["가격 책정 Pricing"]
    CAT -- "가격 조회" --> PRICE
    PRICE --> PORDER["가격이 책정된 주문"]
    PORDER --> SHIP["배송/청구 부서로 전송"]
    PORDER --> ACK["고객에게 주문 확인서 전송"]

• 하지만 이 다이어그램만으로는 지금까지 학습한 모든 내용을 담아낼 수 없음 → 텍스트 기반 미니 언어로 더 정교하게 표현해야 함

2.6.1 제약 사항 표현하기

• 가장 원시적인 값(제품 코드, 수량)부터 시작 — 단순 문자열/정수가 아니라 다양한 방식으로 제약되어 있음을 학습함

제품 코드 제약

context: Order-Taking

data WidgetCode = string starting with "W" then 4 digits
data GizmoCode = string starting with "G" then 3 digits
data ProductCode = WidgetCode OR GizmoCode

// context: Order-Taking

// TypeScript에는 F#처럼 패턴 제약을 표현하는 타입이 기본으로 없으므로
// 브랜디드 타입(branded type) + 파서 함수로 형식 제약을 표현함
type WidgetCode = string & { readonly __brand: "WidgetCode" }; // "W" + 숫자 4자리
type GizmoCode = string & { readonly __brand: "GizmoCode" };   // "G" + 숫자 3자리
type ProductCode = WidgetCode | GizmoCode;

function parseWidgetCode(code: string): WidgetCode {
  if (!/^W\d{4}$/.test(code)) {
    throw new Error(`유효하지 않은 WidgetCode: ${code}`);
  }
  return code as WidgetCode;
}

function parseGizmoCode(code: string): GizmoCode {
  if (!/^G\d{3}$/.test(code)) {
    throw new Error(`유효하지 않은 GizmoCode: ${code}`);
  }
  return code as GizmoCode;
}

• Ollie가 사용한 단어(WidgetCode 등)를 그대로 설계에 사용하여 유비쿼터스 언어의 일부로 취급함
• 두 코드 유형에 대한 제약을 문서화한 뒤, 이 둘의 선택(choice)으로 ProductCode를 정의함
• 의문: 너무 엄격한 설계가 아닌가? 새로운 제품 유형이 생기면 어떻게 하는가
  • 흔한 딜레마: 너무 엄격하면 변경이 어렵고, 너무 자유로우면 설계 자체가 없는 것과 같음
  • 정답은 상황에 따라 다르지만, 일반적으로 도메인 전문가의 관점을 최대한 반영하는 것이 중요함
  • 코드 종류를 구분해 검사하는 것은 검증 프로세스의 중요한 부분이므로 도메인 설계에 자체 문서화(self-documenting) 형태로 반영하는 것이 바람직함 — 여기에 문서화하지 않으면 결국 다른 곳에 문서화해야 함
  • 요구사항이 바뀌어도 이 모델은 변경이 쉬움 (새 제품 코드 유형 추가는 한 줄만 추가하면 됨)
  • 설계가 엄격하다고 해서 구현까지 엄격해야 하는 것은 아님 — 예를 들어 자동화된 검증 로직은 이상한 코드를 무조건 거부하는 대신 사람의 검토를 위해 표시만 남길 수도 있음

주문 수량 제약

data OrderQuantity = UnitQuantity OR KilogramQuantity
data UnitQuantity = integer between 1 and ?
data KilogramQuantity = decimal between ? and ?

• 위 초안을 작성하며 상한선이 없다는 것을 깨달음 — UnitQuantity가 수십억이 될 수는 없음
• 도메인 전문가에게 확인한 제약 사항
  • 주문 가능한 최대 유닛 수: 1,000
  • 최소 무게: 0.05kg, 최대 무게: 100kg
• ==이런 제약을 정확히 포착하는 것이 중요함 — 운영 환경에서 수량이 음수가 되거나 무게가 수백 톤이 되는 상황을 방지해야 함==

data UnitQuantity = integer between 1 and 1000
data KilogramQuantity = decimal between 0.05 and 100.00

type UnitQuantity = number & { readonly __brand: "UnitQuantity" };         // 1 ~ 1000 사이의 정수
type KilogramQuantity = number & { readonly __brand: "KilogramQuantity" }; // 0.05 ~ 100.00 사이의 소수
type OrderQuantity = UnitQuantity | KilogramQuantity;

function parseUnitQuantity(n: number): UnitQuantity {
  if (!Number.isInteger(n) || n < 1 || n > 1000) {
    throw new Error(`유효하지 않은 UnitQuantity: ${n}`);
  }
  return n as UnitQuantity;
}

function parseKilogramQuantity(n: number): KilogramQuantity {
  if (n < 0.05 || n > 100.0) {
    throw new Error(`유효하지 않은 KilogramQuantity: ${n}`);
  }
  return n as KilogramQuantity;
}

2.6.2 주문의 생애 주기 표현하기

• 이제 Order 개념 자체를 재검토
• 초기 정의(너무 단순함)

data Order =
  CustomerInfo
  AND ShippingAddress
  AND BillingAddress
  AND list of OrderLines
  AND AmountToBill

• 이 정의는 Ollie가 실제로 주문을 어떻게 사고하는지를 담아내지 못함
• Ollie의 정신 모델에서 주문은 ==생애 주기(life cycle)== 를 가짐: 미검증(unvalidated, 우편물 그대로) → 검증됨(validated) → 가격 책정됨(priced)
  • 초반에는 가격이 없다가, 마지막에는 가격이 있음 — 위의 단순한 Order 정의는 이 구분을 지워버림
• 종이 양식에서 Ollie는 각 단계가 끝날 때마다 표시를 남겨, 미검증/검증됨/가격 책정됨 양식을 한눈에 구분함
• 이 단계 구분을 도메인 모델에도 반영해야 함 — 단순한 문서화 목적뿐 아니라, (예를 들어) 가격이 매겨지지 않은 주문이 배송 부서로 전달되어서는 안 된다는 규칙을 명시적으로 드러내기 위함
• 접근법: 각 단계마다 새로운 타입 이름을 부여 (UnvalidatedOrder, ValidatedOrder 등)
  • 설계가 길어지고 작성이 번거로워지는 단점이 있으나, 모든 것이 명확해지는 장점이 있음

미검증 주문 (UnvalidatedOrder)

data UnvalidatedOrder =
  UnvalidatedCustomerInfo
  AND UnvalidatedShippingAddress
  AND UnvalidatedBillingAddress
  AND list of UnvalidatedOrderLine

data UnvalidatedOrderLine =
  UnvalidatedProductCode
  AND UnvalidatedOrderQuantity

• 워크플로우 시작 시점에는 CustomerInfo, ShippingAddress 등이 아직 검증되지 않은 상태임을 명시적으로 드러냄

interface UnvalidatedOrder {
  customerInfo: UnvalidatedCustomerInfo;
  shippingAddress: UnvalidatedShippingAddress;
  billingAddress: UnvalidatedBillingAddress;
  orderLines: UnvalidatedOrderLine[];
}

interface UnvalidatedOrderLine {
  productCode: UnvalidatedProductCode;
  orderQuantity: UnvalidatedOrderQuantity;
}

검증된 주문 (ValidatedOrder)

data ValidatedOrder =
  ValidatedCustomerInfo
  AND ValidatedShippingAddress
  AND ValidatedBillingAddress
  AND list of ValidatedOrderLine

data ValidatedOrderLine =
  ValidatedProductCode
  AND ValidatedOrderQuantity

• 모든 구성 요소가 검증을 마쳤고 유효함을 보여줌

interface ValidatedOrder {
  customerInfo: ValidatedCustomerInfo;
  shippingAddress: ValidatedShippingAddress;
  billingAddress: ValidatedBillingAddress;
  orderLines: ValidatedOrderLine[];
}

interface ValidatedOrderLine {
  productCode: ValidatedProductCode;
  orderQuantity: ValidatedOrderQuantity;
}

가격이 책정된 주문 (PricedOrder)

• ValidatedOrder와 거의 같지만 다음이 추가됨
  • 각 라인에 가격이 붙음: PricedOrderLine = ValidatedOrderLine + LinePrice
  • 주문 전체에 AmountToBill이 붙음 (라인 가격들의 합계)

data PricedOrder =
  ValidatedCustomerInfo
  AND ValidatedShippingAddress
  AND ValidatedBillingAddress
  AND list of PricedOrderLine // ValidatedOrderLine과 다름
  AND AmountToBill // 새로 추가됨

data PricedOrderLine =
  ValidatedOrderLine
  AND LinePrice // 새로 추가됨

interface PricedOrder {
  customerInfo: ValidatedCustomerInfo;
  shippingAddress: ValidatedShippingAddress;
  billingAddress: ValidatedBillingAddress;
  orderLines: PricedOrderLine[]; // ValidatedOrderLine과 다름
  amountToBill: AmountToBill;    // 새로 추가됨
}

interface PricedOrderLine extends ValidatedOrderLine {
  linePrice: LinePrice; // 새로 추가됨
}

주문 확인 (PlacedOrderAcknowledgment)

data PlacedOrderAcknowledgment =
  PricedOrder
  AND AcknowledgmentLetter

interface PlacedOrderAcknowledgment {
  pricedOrder: PricedOrder;
  acknowledgmentLetter: AcknowledgmentLetter;
}

• 이 설계에는 이미 비즈니스 로직이 상당히 반영되어 있음
  • 규칙 1: 미검증 주문에는 가격이 없음
  • 규칙 2: 검증된 주문의 모든 라인은 예외 없이 검증되어 있어야 함 (일부만 검증된 상태는 허용되지 않음)
• 모델이 처음 생각보다 훨씬 복잡해졌지만, 이는 실제 비즈니스가 동작하는 방식을 그대로 반영한 결과임 — 모델이 이 정도로 복잡하지 않았다면 오히려 요구사항을 제대로 담아내지 못했다는 뜻
• 이러한 구분을 코드에도 그대로 보존할 수 있다면, 진정한 의미의 “도메인 주도” 설계가 됨

2.6.3 작업 흐름의 단계 구체화하기

• 워크플로우는 검증, 가격 책정 등 더 작은 단계(step)로 나눌 수 있음 → 각 단계에도 동일한 입력/출력 접근법을 적용

• 전체 워크플로우의 출력이 처음 생각보다 복잡해짐

  • 원래는 단순히 “Order placed” 이벤트 하나였지만, 이제는
    • “Order placed” 이벤트를 배송/청구 부서로 보내거나, 또는
    • 주문서를 유효하지 않은 주문 더미에 추가하고 나머지 단계를 건너뜀

전체 워크플로우 의사코드

workflow "Place Order" =
  input: OrderForm
  output:
    OrderPlaced event (put on a pile to send to other teams)
    OR InvalidOrder (put on appropriate pile)

  // step 1
  do ValidateOrder
  If order is invalid then:
    add InvalidOrder to pile
    stop

  // step 2
  do PriceOrder

  // step 3
  do SendAcknowledgmentToCustomer

  // step 4
  return OrderPlaced event (if no errors)

type PlaceOrderResult = OrderPlacedEvent | InvalidOrder;

function placeOrder(orderForm: OrderForm): PlaceOrderResult {
  // step 1
  const validationResult = validateOrder(orderForm);
  if (validationResult.kind === "InvalidOrder") {
    addToPile(validationResult); // 적합한 더미(pile)에 추가
    return validationResult;     // 여기서 중단
  }

  // step 2
  const pricedOrder = priceOrder(validationResult.order);

  // step 3
  sendAcknowledgmentToCustomer(pricedOrder);

  // step 4
  return { kind: "OrderPlaced", order: pricedOrder };
}

ValidateOrder 서브스텝

• 입력: UnvalidatedOrder
• 출력: ValidatedOrder 또는 ValidationError
• 의존성: CheckProductCodeExists, CheckAddressExists

substep "ValidateOrder" =
  input: UnvalidatedOrder
  output: ValidatedOrder OR ValidationError
  dependencies: CheckProductCodeExists, CheckAddressExists

  validate the customer name
  check that the shipping and billing address exist
  for each line:
    check product code syntax
    check that product code exists in ProductCatalog
  if everything is OK, then:
    return ValidatedOrder
  else:
    return ValidationError

type ValidateOrder = (
  unvalidatedOrder: UnvalidatedOrder,
  checkProductCodeExists: (code: ProductCode) => boolean,
  checkAddressExists: (address: UnvalidatedAddress) => boolean
) => ValidatedOrder | ValidationError;

// 의사코드 형태의 구현 스케치 (상세 구현은 이후 도메인 모델링 장에서 다룸)
const validateOrder: ValidateOrder = (order, checkProductCodeExists, checkAddressExists) => {
  // 1. 고객 이름 검증
  // 2. 배송지/청구지 주소 존재 여부 확인 (checkAddressExists)
  // 3. 각 라인에 대해 제품 코드 형식(syntax) 검증
  // 4. 각 라인에 대해 제품 카탈로그 내 존재 여부 확인 (checkProductCodeExists)
  // 5. 문제 없으면 ValidatedOrder 반환, 아니면 ValidationError 반환
  throw new Error("상세 구현은 이후 장에서 다룸");
};

PriceOrder 서브스텝

• 입력: ValidatedOrder
• 출력: PricedOrder
• 의존성: GetProductPrice

substep "PriceOrder" =
  input: ValidatedOrder
  output: PricedOrder
  dependencies: GetProductPrice

  for each line:
    get the price for the product
    set the price for the line
  set the amount to bill ( = sum of the line prices)

type PriceOrder = (
  validatedOrder: ValidatedOrder,
  getProductPrice: (code: ProductCode) => Price
) => PricedOrder;

const priceOrder: PriceOrder = (order, getProductPrice) => {
  // 각 라인마다 가격 조회 후 LinePrice 설정
  // amountToBill = 모든 라인 가격의 합계
  throw new Error("상세 구현은 이후 장에서 다룸");
};

SendAcknowledgmentToCustomer 서브스텝

• 입력: PricedOrder
• 출력: 없음 (None)

substep "SendAcknowledgmentToCustomer" =
  input: PricedOrder
  output: None

  create acknowledgment letter and send it
  and the priced order to the customer

type SendAcknowledgmentToCustomer = (pricedOrder: PricedOrder) => void;

const sendAcknowledgmentToCustomer: SendAcknowledgmentToCustomer = (pricedOrder) => {
  // 주문 확인서(acknowledgment letter) 생성
  // 확인서와 PricedOrder 정보를 고객에게 함께 발송
};

• 이 시점의 문서는 점점 코드에 가까워지지만, 여전히 도메인 전문가가 읽고 검토할 수 있는 수준을 유지함

2.7 마무리

• 이 장에서는 요구사항 수집을 여기서 마무리하고, 이후 2부(모델링 단계)에서 이 내용을 계속 활용함
• 이 장에서 배운 핵심 내용
  • 설계 과정에서 구현 세부 사항에 바로 뛰어들지 않는 것이 중요함: DDD는 데이터베이스 중심도, 클래스 중심도 아니어야 함
  • 대신 특정 코딩 방식을 전제하지 않고, 아무런 가정 없이 도메인 자체를 포착하는 데 집중해야 함
  • 도메인 전문가의 말을 주의 깊게 경청하면, 비교적 단순해 보이는 시스템에서도 상당한 복잡성이 드러남
  • 예: 처음에는 단일한 “Order” 하나만 있을 것이라 생각했지만, 실제로는 생애 주기 전반에 걸쳐 데이터와 동작이 조금씩 다른 여러 변형(Unvalidated/Validated/Priced 등)이 존재함이 드러남

2.7.1 다음 장 안내

• 다음 단계로는 F# 타입 시스템을 이용해 이 주문 접수 워크플로우를 모델링하는 방법을 살펴볼 예정
• 그 전에 한 걸음 물러나 전체 그림(big picture)을 다시 살펴보고, 완전한 시스템을 소프트웨어 아키텍처로 변환하는 방법을 논의함 — 이것이 다음 장의 주제

챕터 3 함수형 아키텍처

• 목표: 도메인에 대한 이해를 함수형 프로그래밍 원칙 기반의 소프트웨어 아키텍처로 변환하는 방법을 다룸
• 전제: 아직 도메인을 제대로 이해하지 못한 “무지의 정점(peak of ignorance)” 단계이므로, 이 시점에 아키텍처를 깊이 고민하는 것은 시간 낭비
  • 지금은 이벤트 스토밍, 인터뷰 등 요구사항 파악에 시간을 쓰는 것이 최선
• 그럼에도 대략적인 구현 계획은 필요한 이유
  • 빠른 개발 주기에서는 도메인 전체를 이해하기 전에 일부를 먼저 구현해야 하는 경우가 많음
  • 아직 만들어지지 않은 컴포넌트들을 어떻게 맞출지 미리 계획이 있어야 함
  • “워킹 스켈레톤(walking skeleton)”: 시스템 전체 동작 방식을 보여주는 조악한 프로토타입을 만드는 것이 유용
  • 구체적인 구현에 대한 이른 피드백은 지식의 공백을 발견하는 좋은 방법
• 소프트웨어 아키텍처도 그 자체로 하나의 도메인 - 아키텍처를 논할 때도 “유비쿼터스 언어” 원칙을 따라야 함
• Simon Brown의 “C4” 접근법 용어를 채택 - 소프트웨어 아키텍처를 4단계 레벨로 설명

• 좋은 아키텍처의 목표: 컨테이너 - 컴포넌트 - 모듈 사이의 경계를 잘 정의하여, 새 요구사항이 생겼을 때 “변경 비용(cost of change)“을 최소화하는 것

3.1 경계 진 맥락을 자율적인 소프트웨어 컴포넌트로

• 경계 지어진 맥락(Bounded Context)의 전제 조건: 명확한 경계를 가진 자율적인 하위 시스템이어야 함
• 전체 시스템이 단일 모놀리식 배포 단위(C4 기준 하나의 컨테이너)인 경우, 경계 지어진 맥락을 구현하는 방식의 선택지
  1. 잘 정의된 인터페이스를 가진 단순한 모듈
  2. 더 명확한 경계를 가진 독립 컴포넌트 (예: .NET 어셈블리)
  3. 각 경계 지어진 맥락을 별도 컨테이너로 배포 - 전통적인 서비스 지향 아키텍처(SOA)
  4. 개별 워크플로 하나하나를 독립 배포 단위로 만드는 마이크로서비스 아키텍처
• 이 단계에서는 특정 방식에 미리 얽매일 필요 없음
  • 논리적 설계를 배포 가능한 형태로 변환하는 방식 자체는 중요하지 않음
  • 중요한 것은 경계 지어진 맥락들이 결합되지 않고(decoupled) 자율적(autonomous)으로 유지되는 것
• 프로젝트 초반에는 경계를 정확히 정하기 어려움 - 도메인을 더 알아갈수록 경계는 계속 변화한다고 예상해야 함
• 모놀리스가 리팩터링하기 훨씬 쉬움 → 처음에는 모놀리스로 구축하고, 필요할 때만 분리된 컨테이너로 리팩터링하는 것이 좋은 practice
• 처음부터 마이크로서비스로 뛰어들어 “마이크로서비스 프리미엄”(운영상의 추가 부담, Martin Fowler 개념)을 치를 필요 없음
  • 이점이 단점을 명백히 능가한다는 확신이 있을 때만 채택
• 진정으로 결합되지 않은 마이크로서비스 아키텍처를 만드는 것은 까다로움
  • ==마이크로서비스 하나를 껐을 때 다른 것이 깨진다면, 그것은 마이크로서비스 아키텍처가 아니라 “분산 모놀리스(distributed monolith)“에 불과함==

3.2 경계 진 맥락 간의 소통

• 질문: 경계 지어진 맥락들은 서로 어떻게 소통하는가?
  • 예: 주문-접수(order-taking) 맥락이 처리를 마쳤을 때 배송(shipping) 맥락에게 어떻게 알리는가?
• 답: **이벤트(Event)**를 사용

예시 흐름

1. 주문-접수 맥락의 Place-Order 워크플로가 OrderPlaced 이벤트를 발행(emit)
2. OrderPlaced 이벤트가 큐(queue)에 게시(publish)됨
3. 배송 맥락이 OrderPlaced 이벤트를 리스닝
4. 이벤트 수신 시 ShipOrder 커맨드가 생성됨
5. ShipOrder 커맨드가 Ship-Order 워크플로를 시작시킴
6. Ship-Order 워크플로가 성공적으로 끝나면 OrderShipped 이벤트를 발행

flowchart LR
    subgraph OT["Order-Taking"]
        POW["Place-Order Workflow"]
    end
    subgraph SP["Shipping"]
        SOW["Ship-Order Workflow"]
    end
    POW -- "OrderPlaced event" --> Q[("queue")]
    Q -- "ShipOrder command" --> SOW
    SOW -- "OrderShipped event" --> OUT(("다운스트림 맥락"))

• 이 설계는 완전히 결합되지 않은(decoupled) 구조
  • 업스트림 컴포넌트(주문-접수)와 다운스트림 컴포넌트(배송)는 서로를 인지하지 못하고, 오직 이벤트를 통해서만 소통
  • 진정으로 자율적인 컴포넌트가 되려면 이런 종류의 결합도 감소(decoupling)가 핵심
• 이벤트 전달 메커니즘은 선택한 아키텍처에 따라 달라짐
  • 큐(Queue): 버퍼링된 비동기 통신에 적합 - 마이크로서비스나 에이전트 구현에서 우선 선택
  • 모놀리식 시스템: 동일한 큐잉 방식을 내부적으로 쓰거나, 업스트림과 다운스트림 컴포넌트를 단순 함수 호출(direct linkage)로 연결 가능
  • 지금 당장 정할 필요는 없음 - 컴포넌트들이 결합되지 않도록 설계하기만 하면 됨
• 이벤트를 커맨드로 변환하는 핸들러의 위치
  • 다운스트림 맥락의 일부(맥락 경계에 위치)로 둘 수 있음
  • 또는 별도의 라우터(router, Enterprise Integration Patterns의 Message Router 패턴)나 프로세스 매니저(process manager)로서 인프라의 일부로 실행할 수도 있음
  • 이벤트와 커맨드 사이의 결합을 어디에 둘 것인지는 아키텍처 선택에 달림

개념을 코드로 표현하면 (참고용)

F#

type OrderPlaced = OrderPlaced of OrderDto
type ShipOrderCommand = ShipOrderCommand of OrderDto

TypeScript

interface OrderPlacedEvent {
  type: "OrderPlaced";
  order: OrderDto;
}

interface ShipOrderCommand {
  type: "ShipOrder";
  order: OrderDto;
}

3.2.1 경계 진 맥락 간 데이터 전송

• 맥락 간 통신에 쓰이는 이벤트는 단순 신호가 아니라, 다운스트림 컴포넌트가 이벤트를 처리하는 데 필요한 모든 데이터를 포함하는 것이 일반적
  • 예: OrderPlaced 이벤트는 배치된 주문 전체 정보를 포함할 수 있음 → 배송 맥락이 ShipOrder 커맨드를 구성하는 데 필요한 모든 정보를 제공
  • 데이터가 너무 크면, 공유 데이터 저장소에 대한 참조(reference)만 전달하는 방식도 가능
• 맥락 간에 주고받는 데이터 객체는 경계 지어진 맥락 내부의 **도메인 객체(domain object)**와 겉보기엔 비슷하지만 동일한 것이 아님
• 이런 객체를 **DTO(Data Transfer Object)**라고 부름 (DDD 밖에서 유래한 용어를 조금 다르게 사용)
  • OrderPlaced 이벤트에 담긴 OrderDTO는 Order 도메인 객체와 대부분 같은 정보를 담지만, 목적에 맞게 다르게 구조화됨
• 업스트림 맥락 경계에서: 도메인 객체 → DTO로 변환 → JSON/XML 등으로 직렬화(Serialize)

flowchart LR
    subgraph DB1["도메인 경계 (Domain Boundary)"]
        A["Domain Type"] --> B["Domain Type to DTO"]
        B --> C["DTO Type"]
    end
    C --> D["Serialize"]
    D --> E["JSON / XML"]
    E --> F(["다운스트림 맥락으로"])

• 다운스트림 맥락에서는 반대 과정이 반복됨: JSON/XML 역직렬화 → DTO → 도메인 객체로 변환

flowchart LR
    A(["업스트림 맥락으로부터"]) --> B["JSON / XML"]
    B --> C["Deserialize"]
    C --> D["DTO Type"]
    subgraph DB2["도메인 경계 (Domain Boundary)"]
        D --> E["DTO to Domain Type"]
        E --> F["Domain Type"]
    end

• 실무에서 직렬화되는 최상위 DTO는 보통 이벤트 DTO이며, 그 안에 하위 DTO(예: Order용 DTO)를 포함하고, 그 하위 DTO가 다시 추가 하위 DTO(예: OrderLines 리스트)를 포함하는 중첩 구조를 가짐

DTO 예시 (개념 표현, 참고용)

F#

type OrderDto = {
    OrderId: string
    CustomerId: string
    ShippingAddress: AddressDto
    Lines: OrderLineDto list
}

TypeScript

interface OrderDto {
  orderId: string;
  customerId: string;
  shippingAddress: AddressDto;
  lines: OrderLineDto[];
}

3.2.2 신뢰 경계와 검증

• 경계 지어진 맥락의 경계(perimeter)는 “신뢰 경계(trust boundary)” 역할을 함
  • 맥락 내부: 신뢰되고 유효한 것으로 간주
  • 맥락 외부: 신뢰할 수 없고 무효할 수 있는 것으로 간주
• 따라서 워크플로의 시작과 끝에, 신뢰된 도메인과 신뢰할 수 없는 외부 세계를 중재하는 **“게이트(gate)”**를 둠

flowchart LR
    U1["신뢰할 수 없는 외부 세계"] -.-> D1(["DTO"])
    D1 --> IG(("입력 게이트<br/>input gate"))
    subgraph TRUSTED["신뢰된, 깨끗한 도메인 모델"]
        IG --> WF["Workflow"]
        WF --> OG(("출력 게이트<br/>output gate"))
    end
    OG --> D2(["DTO"])
    D2 -.-> U2["신뢰할 수 없는 외부 세계"]

• 입력 게이트(input gate): 입력이 도메인 모델의 제약 조건을 만족하는지 항상(always) 검증
  • 예: Order의 특정 속성이 null이 아니고 50자 미만이어야 한다는 제약이 있을 때, 수신된 OrderDTO는 이런 제약이 없어 무엇이든 담길 수 있음. 입력 게이트에서 검증을 통과해야만 Order 도메인 객체가 유효함을 보장할 수 있음
  • 검증 실패 시: 나머지 워크플로는 우회(bypass)되고 오류가 생성됨
• 출력 게이트(output gate): 역할이 다름 - 비공개 정보가 경계 지어진 맥락 밖으로 유출되지 않도록 보장 (맥락 간 의도치 않은 결합 방지 + 보안 목적)
  • 예: 배송 맥락은 주문 결제에 쓰인 신용카드 번호를 알 필요가 없음
  • 출력 게이트는 도메인 객체를 DTO로 변환하는 과정에서 (카드번호 같은) 정보를 의도적으로 “잃어버림(lose)”

3.3 경계 진 맥락 간의 계약

• 맥락 간 결합을 최대한 줄이고 싶지만, 공유되는 통신 포맷은 필연적으로 어느 정도의 결합을 유발함
  • 이벤트와 관련 DTO는 경계 지어진 맥락 간의 일종의 **“계약(contract)”**을 형성
  • 두 맥락은 성공적인 소통을 위해 공통 포맷에 합의해야 함
• 누가 계약을 결정하는가? DDD 커뮤니티가 정립한 세 가지 대표적 관계 유형

3.3.1 부패 방지 계층

• 외부 시스템과 통신할 때, 사용 가능한 인터페이스가 우리 도메인 모델과 전혀 맞지 않는 경우가 흔함
• 이 경우 상호작용과 데이터를 경계 지어진 맥락 내부에서 쓰기 적합한 형태로 변환해야 함
  • 그렇지 않으면 도메인 모델이 외부 시스템 모델에 적응하려다 **“부패(corrupted)”**됨
• 이러한 맥락 간 결합 완화 계층을 DDD 용어로 **부패 방지 계층(Anti-Corruption Layer, ACL)**이라 부름
• 3.2.2절의 다이어그램에서 “입력 게이트”가 종종 ACL 역할을 함께 수행
  • 내부의 순수한 도메인 모델이 외부 세계에 대한 지식으로 “부패”되는 것을 방지
• ==ACL은 근본적으로 검증이나 데이터 손상 방지가 목적이 아니라, 서로 다른 두 언어(업스트림 맥락의 언어, 다운스트림 맥락의 언어) 사이를 번역하는 통역자 역할==
  • 예: 주문-접수 예제에서 “주문-접수” 어휘를 “배송” 어휘로 번역하는 ACL을 두면, 각자의 어휘를 가진 두 맥락이 독립적으로 진화 가능

3.3.2 맥락 간 관계를 나타내는 맥락 지도

• 설계가 진행되어 맥락 간 관계가 다음과 같이 결정되었다고 가정

• 서드파티 컴포넌트를 사용할 때 흔한 패턴 - 벤더 락인을 방지하고, 이후 다른 서비스로 교체 가능하게 함

flowchart TD
    AC["Address Checking"] -- "ACL" --> OT["Order-taking"]
    PC["Product Catalog"] -- "Conformist" --> OT
    OT -- "Shared Kernel" --> SH["Shipping"]
    OT -- "Consumer Driven" --> BI["Billing"]

• 이 맥락 지도는 이제 순수한 기술적 관계뿐 아니라, 맥락을 소유하는 팀 간의 관계와 그들이 어떻게 협업할 것으로 예상되는지(혹은 협업하지 않을지)도 함께 보여줌
• 도메인 간 상호작용 방식 결정은 기술적 과제만큼이나 조직적 과제
  • 일부 팀은 **“역 콘웨이 전략(inverse Conway maneuver)”**을 사용하여 조직 구조를 아키텍처에 맞춤

3.4 경계 진 맥락의 작업 흐름

• 발견(discovery) 과정에서는 비즈니스 워크플로를 커맨드에 의해 시작되어 하나 이상의 도메인 이벤트를 생성하는 미니 프로세스로 취급
• 함수형 아키텍처에서는 각 워크플로를 단일 함수(single function)로 매핑
  • 입력: 커맨드 객체
  • 출력: 이벤트 객체의 리스트

개념을 코드로 표현하면 (참고용)

F#

type Workflow<'Command, 'Event> = 'Command -> 'Event list

TypeScript

type Workflow<TCommand, TEvent> = (command: TCommand) => TEvent[];

• 설계 다이어그램에서 워크플로는 입력과 출력이 있는 작은 파이프(pipe)로 표현
  • 공개 워크플로(public workflow): 경계 지어진 맥락 외부에서 트리거되는 워크플로 - 경계 위로 약간 “튀어나온(sticking out)” 형태로 표시
  • 내부 워크플로(internal workflow): 맥락 내부에서만 호출됨

flowchart TB
    subgraph BC["Bounded Context"]
        C1["Command"] --> PW1["Public Workflow"] --> E1["Events"]
        C2["Command"] --> PW2["Public Workflow"] --> E2["Events"]
        IW["Internal Workflow"]
    end

• ==워크플로는 항상 단일 경계 지어진 맥락 내에 포함되며, 여러 맥락을 거쳐 “엔드투엔드(end-to-end)“로 시나리오를 구현하지 않음==

3.4.1 작업 흐름 입력 및 출력

• 워크플로의 입력은 항상 커맨드와 연관된 데이터, 출력은 항상 다른 맥락에 전달할 이벤트 집합
  • 주문-배치(order-placing) 워크플로 예: 입력은 PlaceOrder 커맨드 데이터, 출력은 OrderPlaced 이벤트 등 이벤트 집합
• 청구 맥락과 “고객/공급자” 관계가 정해졌으므로, 배송용 범용 OrderPlaced 이벤트를 청구 맥락에 그대로 보내는 대신, 청구가 필요로 하는 정보만 정확히 보내야 함
  • 예: 청구 주소와 청구할 총액만 필요 - 배송 주소나 품목 목록은 불필요
• 따라서 워크플로에서 새로운 이벤트(BillableOrderPlaced)를 발행해야 함

원서 예시 (원서의 경량 표기법)

data BillableOrderPlaced =
    OrderId
    AND BillingAddress
    AND AmountToBill

실제 F# 레코드 타입 스타일로 표현하면

type BillableOrderPlaced = {
    OrderId: OrderId
    BillingAddress: Address
    AmountToBill: BillingAmount
}

TypeScript로 표현하면

interface BillableOrderPlaced {
  orderId: OrderId;
  billingAddress: Address;
  amountToBill: BillingAmount;
}

• OrderAcknowledgmentSent 이벤트도 함께 발행될 수 있음
• 이런 변경으로 인해 이전(원서 29쪽)의 단순한 워크플로 다이어그램은 부정확해졌으므로 아래처럼 업데이트 필요

flowchart LR
    IN["Input:<br/>Order form"] --> WF["Workflow:<br/>Place Order"]
    WF --> EV1["OrderAcknowledgmentSent"]
    WF --> EV2["OrderPlaced event<br/>(for Shipping)"]
    WF --> EV3["BillableOrderPlaced event<br/>(for Billing)"]
    WF -. "side effect" .-> SE["주문 확인서를<br/>고객에게 발송"]

• ==이 다이어그램에서 중요한 점: 워크플로 함수는 도메인 이벤트를 “발행(publish)“하지 않고 단순히 반환(return)할 뿐임. 이벤트가 실제로 어떻게 발행되는지는 별도의 관심사==

3.4.2 경계 진 맥락 내 도메인 이벤트 금지

• 객체지향 설계에서는 경계 지어진 맥락 내부에서 도메인 이벤트를 발생(raise)시키는 것이 일반적
  • 워크플로 객체가 OrderPlaced 이벤트를 발생시킴
  • 핸들러가 이 이벤트를 리스닝해 주문 확인서를 발송
  • 다른 핸들러가 BillableOrderPlaced 이벤트를 생성
  • …

flowchart LR
    IN["Input:<br/>Order form"] --> WF["Workflow:<br/>Place Order"]
    WF --> OP["OrderPlaced event"]
    OP -. "listen" .-> L1["Event listener:<br/>Acknowledge Order"]
    L1 --> EV1["OrderAcknowledgmentSent"]
    L1 -. "side effect" .-> SE["주문 확인서 발송"]
    OP -. "listen" .-> L2["Event listener:<br/>Create BillableOrder"]
    L2 --> EV2["BillableOrderPlaced"]

• 함수형 설계에서는 이 방식을 선호하지 않음 - **숨겨진 의존성(hidden dependency)**을 만들기 때문
• 대신 이벤트에 대한 “리스너”가 필요하면, 단순히 워크플로의 끝에 이어 붙임(append)

flowchart LR
    IN["Input:<br/>Order form"] --> WF["Workflow:<br/>Place Order"]
    WF --> AO["Acknowledge Order"]
    AO --> CB["Create BillableOrder"]
    AO --> EV1["OrderAcknowledgmentSent"]
    AO -. "side effect" .-> SE["주문 확인서 발송"]
    CB --> EV2["OrderPlaced event"]
    CB --> EV3["BillableOrderPlaced"]

• ==이 접근법이 더 명시적(explicit) - 가변 상태(mutable state)를 가진 전역 이벤트 매니저가 없음 → 이해하고 유지보수하기 쉬움==
• 구현(Implementation) 장(원서 161쪽)과 설계 진화(Evolving A Design) 장(원서 265쪽)에서 실제 적용 사례를 다룸

두 접근법 비교

3.5 경계 진 맥락의 코드 구조

• 경계 지어진 맥락 내부의 코드가 어떻게 구조화되는지 살펴봄
• 전통적인 “계층형 접근(layered approach)”: 핵심 도메인/비즈니스 로직 계층, 데이터베이스 계층, 서비스 계층, API/사용자 인터페이스 계층(또는 변형)으로 코드를 분할
  • 워크플로는 최상위 계층에서 시작해 데이터베이스 계층까지 내려갔다가 다시 최상위로 반환됨

flowchart TD
    W1["Workflow"] --> API["API / Interface Layer"]
    W2["Workflow"] --> API
    API --> SVC["Services Layer"]
    SVC --> DOM["Domain Layer"]
    DOM --> DBL["Database Layer"]
    DBL -. "반환" .-> DOM
    DOM -. "반환" .-> SVC
    SVC -. "반환" .-> API

• 이 접근법의 문제점
  • ==**“함께 변경되는 코드는 함께 있어야 한다(code that changes together belongs together)”**는 중요한 설계 원칙을 위반==
  • 계층이 “수평적으로(horizontally)” 조립되어 있어, 워크플로의 동작 방식이 바뀌면 모든 계층을 건드려야 함
• 더 나은 방법: “수직(vertical)” 슬라이스로 전환
  • 각 워크플로가 자신에게 필요한 모든 코드를 포함
  • 워크플로의 요구사항이 바뀌면 해당 수직 슬라이스의 코드만 변경하면 됨

flowchart TD
    subgraph S1["워크플로 1 (수직 슬라이스)"]
        A1["API/Interface"] --> B1["Services"] --> C1["Domain"] --> D1["Database"]
    end
    subgraph S2["워크플로 2 (수직 슬라이스)"]
        A2["API/Interface"] --> B2["Services"] --> C2["Domain"] --> D2["Database"]
    end

• 이것도 완벽하지 않음 - 워크플로를 수평 파이프로 늘려서 계층들을 다시 살펴보면, 계층이 뒤섞여(intermingled) 등장함

flowchart LR
    S(("Workflow 시작")) --> N1["API/Interface"]
    N1 --> N2["Domain"]
    N2 --> N3["Services"]
    N3 --> N4["Domain"]
    N4 --> N5["Database"]
    N5 --> N6["API/Interface"]
    N6 --> E(("Workflow"))

• ==계층이 뒤섞여 있어(intermingled) 로직을 이해하고 테스트하기가 불필요하게 복잡해짐==

3.5.1 양파 아키텍처

• 대신 도메인 코드를 중심에 두고, 그 주위에 다른 관심사들을 조립
  • 규칙: 각 계층은 오직 안쪽 계층에만 의존할 수 있고, 바깥쪽 계층에는 의존할 수 없음
  • ==즉, 모든 의존성은 안쪽을 향해야(point inward) 함==
• 이를 **“양파 아키텍처(Onion Architecture)”**라고 부름 (Jeffrey Palermo)

flowchart LR
    subgraph L1["Database / Infrastructure"]
        subgraph L2["API / Interface"]
            subgraph L3["Services"]
                subgraph L4["Domain (핵심 도메인)"]
                    CORE(("비즈니스 로직"))
                end
            end
        end
    end
    WF(("Workflow")) --> CORE
    CORE --> WF

• 유사한 접근법
  • 헥사고날 아키텍처(Hexagonal Architecture) (Alistair Cockburn)
  • 클린 아키텍처(Clean Architecture) (“Uncle Bob” Robert C. Martin)
• 모든 의존성이 안쪽을 향하도록 하려면, 함수형 버전의 **의존성 주입(dependency injection)**이 필요
  • “구현: 파이프라인 조합(Implementation: Composing a Pipeline)” 장에서 상세히 다룸

3.5.2 외부 입출력을 맥락 경계로 내몰기

• 함수형 프로그래밍의 주요 목표: 내부를 들여다보지 않고도 예측 가능하고 추론하기 쉬운 함수로 작업하는 것
• 이를 위한 실천 방법
  • 가능한 한 **불변 데이터(immutable data)**를 사용
  • 함수가 숨겨진 의존성 대신 명시적(explicit) 의존성을 갖도록 함
  • ==가장 중요한 것: 함수 내 사이드 이펙트(side effect)를 피함 - 무작위성(randomness), 함수 외부 변수의 변경(mutation), 그리고 무엇보다 모든 종류의 I/O==
• 데이터베이스나 파일 시스템을 읽거나 쓰는 함수는 **“불순(impure)”**한 것으로 간주 → 핵심 도메인에서는 이런 함수를 피함

개념을 코드로 표현하면 (참고용)

F#

// 순수 함수 - 핵심 도메인 로직, 사이드 이펙트 없음
let validateOrder : UnvalidatedOrder -> Result<ValidatedOrder, ValidationError> =
    fun order -> failwith "구현 생략"

// 불순 함수 - I/O 포함, 인프라스트럭처 관심사이므로 도메인 계층에서 배제
let saveOrder : ValidatedOrder -> Async<unit> =
    fun order -> failwith "구현 생략"

TypeScript

// 순수 함수 - 핵심 도메인 로직, 사이드 이펙트 없음
type ValidateOrder = (
  order: UnvalidatedOrder
) => Result<ValidatedOrder, ValidationError>;

// 불순 함수 - I/O 포함, 인프라스트럭처 관심사이므로 도메인 계층에서 배제
type SaveOrder = (order: ValidatedOrder) => Promise<void>;

• 그렇다면 데이터를 어떻게 읽고 쓰는가?
  • 답: 모든 I/O를 양파의 가장자리(edge)로 밀어냄
  • 예: 데이터베이스 접근은 워크플로의 시작이나 끝에서만 이루어지고, 워크플로 내부에서는 이루어지지 않음
• 부가적인 이점: 관심사 분리를 강제함
  • 핵심 도메인 모델은 오직 비즈니스 로직에만 관심을 가짐
  • 영속성(persistence)과 기타 I/O는 인프라스트럭처의 관심사가 됨
• 이는 앞서 2장에서 소개된 “영속성 무지(persistence ignorance)” 개념과 잘 맞물림
  • ==워크플로 내부에서 데이터베이스에 접근조차 할 수 없다면, 애초에 데이터베이스를 사용해 도메인을 모델링할 수 없음==
  • Persistence 장에서 상세히 다룸

3.6 마무리

• 이번 장에서 소개된 DDD 관련 개념과 용어 정리

3.6.1 다음 장 안내

• 도메인에 대한 이해와, 솔루션을 설계하는 일반적인 접근법을 갖췄으므로, 다음은 개별 워크플로를 모델링하고 구현하는 과제로 이동
• 다음 몇 개 장에서는 F# 타입 시스템을 사용해 워크플로와 그것이 사용하는 데이터를 정의
  • 목표: 도메인 전문가와 비개발자도 이해할 수 있는, 컴파일 가능한 코드를 작성
• 그에 앞서 필요한 선행 이해
  • 함수형 프로그래머에게 **“타입(type)”**이 무엇을 의미하는지
  • 그것이 객체지향 설계의 **“클래스(class)”**와 어떻게 다른지
• 이것이 다음 장(챕터 4)의 주제

파트 2 도메인 모델링하기

• 도메인의 워크플로 하나를 골라 함수형 방식으로 모델링하는 파트
• 함수형 도메인 분해가 객체지향 접근과 어떻게 다른지 확인
• 타입을 이용해 요구사항을 어떻게 포착하는지 학습
• 목표: 다음 두 가지 역할을 동시에 하는 간결한 코드를 작성하는 것
  • 도메인에 대한 가독성 있는 문서
  • 나머지 구현이 그 위에 쌓일 수 있는, 컴파일되는 프레임워크

챕터 4 타입 이해하기

• 2장에서 주문 처리 시스템의 한 워크플로에 대한 도메인 주도 요구사항을 이미 포착함
• 이번 장의 과제: 그 비정형 요구사항을 컴파일 가능한 코드로 변환하는 것
• 채택하는 접근법: F#의 “대수적 타입 시스템”(algebraic type system)으로 요구사항을 표현
• 이번 장에서 학습할 것
  • 대수적 타입이 무엇인지
  • 대수적 타입을 어떻게 정의하고 사용하는지
  • 대수적 타입으로 도메인 모델을 어떻게 표현하는지
• 다음 장(5장)에서는 이번 장 내용을 바탕으로 주문 처리 워크플로를 정확히 모델링함

4.1 함수 이해하기

• 타입을 이해하기 전에 먼저 함수형 프로그래밍에서 가장 기초적인 개념인 함수(function)를 이해해야 함
• 고등학교 수학의 함수 개념: 입력과 출력이 있는 일종의 블랙박스
• 비유: 철로 위에 놓인 “변환의 터널”(Tunnel of Transformation)
  • 무언가가 들어가서, 어떤 방식으로 변환되고, 반대편으로 나옴
• 예시: 사과를 바나나로 바꾸는 함수
• 함수는 입력과 출력을 화살표(->)로 구분해서 표기

flowchart LR
    Apple(["사과 Apple"]) --> Tunnel["변환의 터널<br/>Function: Apple → Banana"] --> Banana(["바나나 Banana"])

4.1.1 함수 이해하기

타입 시그니처(Type Signatures)

• apple -> banana 같은 표기를 타입 시그니처(= 함수 시그니처)라고 부름
• 이번 예시는 단순하지만, 타입 시그니처는 매우 복잡해질 수 있음. F# 코딩에서 타입 시그니처를 읽고 쓰는 능력은 필수적
• add1은 입력 하나에 1을 더하고, add는 두 입력 x, y를 더함

let add1 x = x + 1  // signature is: int -> int
let add x y = x + y // signature is: int -> int -> int

// add1: (x: number) => number
const add1 = (x: number): number => x + 1;

// add: (x: number, y: number) => number
const add = (x: number, y: number): number => x + y;

• 함수 정의 문법 특징
  • let 키워드로 함수를 정의
  • 파라미터는 괄호나 콤마 없이 공백으로 구분
  • C#이나 Java와 달리 return 키워드가 없음
  • 함수 정의의 마지막 표현식이 곧 함수의 출력값
• F#은 입력과 출력의 타입을 신경 쓰지만, 대부분의 경우 컴파일러가 자동으로 타입을 추론하므로 명시적으로 선언할 필요가 거의 없음
  • add1: x의 추론된 타입(화살표 앞)은 int, 출력의 추론된 타입(화살표 뒤)도 int → 시그니처는 int -> int
  • add: x, y의 추론된 타입은 int, 출력의 추론된 타입도 int. 파라미터가 두 개이므로 각 파라미터가 화살표로 구분되어 시그니처는 int -> int -> int
• Visual Studio 같은 IDE에서는 함수 정의에 마우스를 올리면 타입 시그니처가 표시됨. 책에서는 필요할 때 정의 위에 주석으로 타입 시그니처를 적어줌(컴파일러가 사용하는 것은 아니고 그냥 주석)
• 여러 줄로 이루어진 함수는 파이썬처럼 들여쓰기로 작성하며, 중괄호가 없음

// squarePlusOne : int -> int
let squarePlusOne x =
  let square = x * x
  square + 1

// squarePlusOne: (x: number) => number
function squarePlusOne(x: number): number {
  const square = x * x;
  return square + 1;
}

• 위 예시는 함수 내부에 서브함수(let square = ...)를 정의할 수 있음을 보여주며, 여기서도 마지막 줄(square + 1)이 반환값

제네릭 타입을 갖는 함수(Functions with Generic Types)

• 함수가 어떤 타입에도 동작한다면, 컴파일러는 자동으로 제네릭 타입을 추론함(areEqual 예시)

// areEqual : 'a -> 'a -> bool
let areEqual x y =
  (x = y)

// areEqual: <T>(x: T, y: T) => boolean
function areEqual<T>(x: T, y: T): boolean {
  return x === y;
}

• areEqual에서 x, y의 추론된 타입은 'a. 작은따옴표 + 문자는 F#에서 제네릭 타입을 나타내는 표기법
• x, y는 같은 타입이기만 하면 어떤 타입이든 될 수 있음
• F#에서 동등 비교 연산자는 = 이며, C 계열 언어의 ==가 아님

static bool AreEqual<T>(T x, T y)
{
    return (x == y);
}

4.2 타입과 함수

• F#과 같은 프로그래밍 언어에서 타입(type)이 무엇을 의미하는지 정리
• ==타입은 객체지향의 클래스(class)와 다름. 훨씬 단순함==
• 타입이란 함수의 입력 또는 출력으로 사용될 수 있는, 가능한 값들의 집합에 붙인 이름일 뿐
• 타입 자체에는 그 이상의 특별한 의미나 동작이 없음

flowchart LR
    subgraph IN["입력값의 집합 Set of valid inputs"]
    end
    subgraph OUT["출력값의 집합 Set of valid outputs"]
    end
    IN --> F["함수 Function<br/>input → output"] --> OUT

• 예: -32768부터 +32767까지의 정수 집합에 int16이라는 이름(label)을 붙임

flowchart LR
    I["-32768, -32767, ...<br/>-2, -1, 0, 1, 2, ...<br/>32766, 32767<br/>(이 값들의 집합이 곧 'int16' 타입)"] --> F["함수 Function<br/>int16 → output"] --> O["출력값의 집합"]

int16 -> someOutputType

type Int16 = number; // 개념상 -32768 ~ 32767 범위로 제한된다고 가정
type Fn = (input: Int16) => SomeOutputType;

• 타입에 속한 값들이 반드시 원시(primitive) 값일 필요는 없음. 아래는 세 가지 예시

someInputType -> string

type Fn = (input: SomeInputType) => string;

• 개념적으로 타입에 속한 것은 실제 사물이든 가상의 것이든 어떤 종류든 될 수 있음(Person, Fruit 예시)
• 함수 역시 하나의 “것”이므로, 함수들의 집합도 타입으로 사용 가능
  • 예: 입력을 받아 “Fruit를 Fruit로 바꾸는 함수”를 출력하는 함수

flowchart LR
    I2["입력값의 집합"] --> F2["함수 Function<br/>input → (Fruit → Fruit)"] --> O2["Fruit → Fruit 함수들의 집합<br/>(타입: 'Fruit → Fruit')"]

• 출력 집합의 각 원소는 Fruit -> Fruit 함수이므로, 전체 함수의 시그니처는 다음과 같음

someInputType -> (Fruit -> Fruit)

type Fn = (input: SomeInputType) => (fruit: Fruit) => Fruit;

용어 정리: “값(Values)” vs “객체(Objects)” vs “변수(Variables)”

• 함수형 프로그래밍 언어에서는 대부분의 것을 “값(value)“이라 부르고, 객체지향 언어에서는 대부분 “객체(object)“라고 부름
• 값(value): 어떤 타입의 구성원. 함수의 입력 또는 출력으로 사용될 수 있는 것. 예: 1은 int 타입의 값, "abc"는 string 타입의 값
• 함수도 값이 될 수 있음. 예를 들어 let add1 x = x + 1을 정의하면 add1은 int -> int 타입의 (함수) 값
• 값은 불변(immutable)임 — 그래서 “변수”라고 부르지 않음. 또한 값에는 어떤 동작(behavior)도 붙어있지 않고, 그저 데이터일 뿐
• 객체(object): 데이터 구조와 그에 결합된 동작(메서드)의 캡슐화. 일반적으로 객체는 상태(mutable)를 가지며, 내부 상태를 바꾸는 모든 연산은 반드시 객체 자신을 통해(점 표기법으로) 제공되어야 함
• 따라서 객체가 존재하지 않는 함수형 프로그래밍 세계에서는 “변수”나 “객체”보다 “값”이라는 용어를 사용해야 함

4.3 타입 합성

• 함수형 프로그래밍에서 “합성(composition)“이라는 단어는 매우 자주 등장하며, 함수형 설계의 근간이 됨
• 합성이란 레고 블록을 조립하듯 두 가지를 결합해 더 큰 것을 만드는 것
• 함수형 프로그래밍 세계에서는 합성을 이용해
  • 작은 함수들로부터 새로운 함수를 만들고(함수 합성은 8장에서 다룸)
  • 작은 타입들로부터 새로운 타입을 만듦(타입 합성은 지금 다룸)
• F#에서 새로운 타입을 만드는 두 가지 방법
  • AND로 결합하기
  • OR로 결합하기

4.3.1 AND 타입

• 예: 과일 샐러드(FruitSalad)를 만들려면 사과 그리고(and) 바나나 그리고 체리가 필요함

flowchart LR
    FS["FruitSalad"] -->|AND| A["Apple: AppleVariety"]
    FS -->|AND| B["Banana: BananaVariety"]
    FS -->|AND| C["Cherries: CherryVariety"]

• F#에서 이런 타입을 **레코드(record)**라고 부름

type FruitSalad = {
  Apple: AppleVariety
  Banana: BananaVariety
  Cherries: CherryVariety
}

type FruitSalad = {
  apple: AppleVariety;
  banana: BananaVariety;
  cherries: CherryVariety;
};

• 중괄호는 레코드 타입임을 나타내며, Apple, Banana, Cherries 세 개의 필드로 구성됨

4.3.2 OR 타입

• 다른 방법은 OR을 사용해 타입을 만드는 것
• 예: 과일 간식(FruitSnack)을 만들려면 사과 또는(or) 바나나 또는 체리 중 하나가 필요함

flowchart LR
    FSN["FruitSnack"] -->|"OR (택1)"| A2["Apple of AppleVariety"]
    FSN -->|"OR (택1)"| B2["Banana of BananaVariety"]
    FSN -->|"OR (택1)"| C2["Cherries of CherryVariety"]

• 이런 “선택(choice)” 타입은 도메인 모델링에서 매우 유용하게 쓰임(책 전체에서 반복적으로 등장)

type FruitSnack =
  | Apple of AppleVariety
  | Banana of BananaVariety
  | Cherries of CherryVariety

type FruitSnack =
  | { kind: "Apple"; value: AppleVariety }
  | { kind: "Banana"; value: BananaVariety }
  | { kind: "Cherries"; value: CherryVariety };

• 이런 선택 타입을 F#에서는 **판별 유니온(discriminated union)**이라고 부름
• 읽는 법: FruitSnack은 (Apple 태그가 붙은) AppleVariety 이거나, (Banana 태그가 붙은) BananaVariety 이거나, (Cherries 태그가 붙은) CherryVariety이다
• 세로 막대(|)로 각 선택지를 구분함
• 태그(Apple, Banana 등)가 필요한 이유: 두 개 이상의 선택지가 같은 타입을 가질 수 있으므로, 이를 구분하기 위한 표식이 필요하기 때문
• 과일의 품종(variety) 자체도 OR 타입으로 정의되며, 이 경우는 다른 언어의 enum과 유사하게 사용됨

type AppleVariety =
  | GoldenDelicious
  | GrannySmith
  | Fuji

type BananaVariety =
  | Cavendish
  | GrosMichel
  | Manzano

type CherryVariety =
  | Montmorency
  | Bing

type AppleVariety = "GoldenDelicious" | "GrannySmith" | "Fuji";
type BananaVariety = "Cavendish" | "GrosMichel" | "Manzano";
type CherryVariety = "Montmorency" | "Bing";

• 읽는 법: AppleVariety는 GoldenDelicious 이거나 GrannySmith 이거나 Fuji이다 (이하 동일)

용어 정리: “곱 타입(Product Types)“과 “합 타입(Sum Types)”

• AND로 만들어진 타입을 **곱 타입(product type)**이라고 부름
• OR로 만들어진 타입을 합 타입(sum type) 또는 태그드 유니온(tagged union), F# 용어로는 **판별 유니온(discriminated union)**이라고 부름. 이 책에서는 도메인 모델링에서의 역할을 가장 잘 설명한다는 이유로 이를 **선택 타입(choice type)**이라고 부름

4.3.3 단순 타입

• 선택지가 단 하나뿐인 선택 타입을 정의하는 경우가 자주 있음

type ProductCode =
  | ProductCode of string

• 이 타입은 거의 항상 다음과 같이 한 줄로 단순화됨

type ProductCode = ProductCode of string

// 태그를 이용한 명목적(nominal) 래퍼 패턴
type ProductCode = { kind: "ProductCode"; value: string };

// 또는 브랜드(brand) 패턴으로 표현
type ProductCode = string & { readonly __brand: "ProductCode" };

• 왜 이런 타입을 만드는가?
  • string이나 int 같은 원시 타입을 내부 값으로 담는 “래퍼(wrapper)” 타입을 손쉽게 만들 수 있기 때문
  • 도메인 모델링을 할 때 이런 타입을 아주 많이 보게 됨
• 이 책에서는 레코드나 판별 유니온 같은 복합 타입과 구분해, 이런 단일 케이스 유니온을 **“단순 타입(simple type)”**이라고 표기함

4.3.4 대수적 타입 시스템

• 이제 “대수적 타입 시스템(algebraic type system)“이 무엇인지 정의할 수 있음
• 생각보다 무섭지 않은 개념: 모든 합성 타입이 더 작은 타입들을 AND 또는 OR로 결합해서 구성되는 타입 시스템을 말함
• F#은 대부분의 함수형 언어와 마찬가지로(그러나 OO 언어와 달리) 내장 대수적 타입 시스템을 가짐
• 타입을 만들 때 사용하는 AND와 OR은, 앞선 장에서 도메인을 문서화할 때 사용했던 AND, OR과 동일한 개념 — 익숙하게 느껴져야 함
• 대수적 타입 시스템은 도메인 모델링에 훌륭한 도구임을 곧 확인하게 됨

4.4 TypeScript 타입 다루기

• F#에서는 타입을 정의하는 방식과 타입의 값을 생성/해체하는 방식이 서로 매우 유사함(대칭적)

레코드 타입: 정의 / 생성 / 해체

• 레코드 타입 정의: 중괄호와 필드명: 타입 목록 사용

type Person = {First:string; Last:string}

• 값 생성: 동일한 중괄호를 사용하되 =로 필드에 값을 대입

let aPerson = {First="Alex"; Last="Adams"}

• 패턴 매칭을 이용한 값 해체(deconstruct): 동일한 문법을 등호 왼쪽에 사용

let {First=first; Last=last} = aPerson

• 위 코드는 first, last 값이 레코드의 해당 필드로 설정됨을 의미
• 레코드는 더 익숙한 점(.) 표기법도 사용 가능 — 위 코드와 동등함

let first = aPerson.First
let last = aPerson.Last

type Person = { first: string; last: string };

// 값 생성
const aPerson: Person = { first: "Alex", last: "Adams" };

// 구조 분해 할당으로 해체
const { first, last } = aPerson;

// 점 표기법
const first2 = aPerson.first;
const last2 = aPerson.last;

판별 유니온: 정의 / 생성 / 해체 대칭성

• 정의: 세로 막대로 선택지를 구분하며, 각 선택지는 케이스라벨 of 타입 형태

type OrderQuantity =
  | UnitQuantity of int
  | KilogramQuantity of decimal

• 생성: 케이스 라벨 중 하나를 생성자 함수로 사용하고, 연관된 데이터를 파라미터로 전달

let anOrderQtyInUnits = UnitQuantity 10
let anOrderQtyInKg = KilogramQuantity 2.5

• 케이스는 서브클래스가 아님. UnitQuantity와 KilogramQuantity는 그 자체로 타입이 아니라, OrderQuantity 타입의 서로 다른 케이스일 뿐임. 위 예시에서 두 값은 모두 동일한 타입 OrderQuantity를 가짐
• 해체: 판별 유니온을 해체하려면 반드시 패턴 매칭(match .. with 문법)을 사용해 각 케이스를 검사해야 함

let printQuantity aOrderQty =
  match aOrderQty with
  | UnitQuantity uQty ->
      printfn "%i units" uQty
  | KilogramQuantity kgQty ->
      printfn "%g kg" kgQty

• 매칭 과정에서 특정 케이스에 연관된 데이터도 함께 사용 가능(uQty 값이 UnitQuantity 케이스에 매칭될 때 설정됨)

printQuantity anOrderQtyInUnits // "10 units"
printQuantity anOrderQtyInKg // "2.5 kg"

type OrderQuantity =
  | { kind: "UnitQuantity"; value: number }
  | { kind: "KilogramQuantity"; value: number };

// 생성
const anOrderQtyInUnits: OrderQuantity = { kind: "UnitQuantity", value: 10 };
const anOrderQtyInKg: OrderQuantity = { kind: "KilogramQuantity", value: 2.5 };

// 해체 (switch 문의 판별 필드로 타입이 좁혀짐 - narrowing)
function printQuantity(aOrderQty: OrderQuantity): string {
  switch (aOrderQty.kind) {
    case "UnitQuantity":
      return `${aOrderQty.value} units`;
    case "KilogramQuantity":
      return `${aOrderQty.value} kg`;
  }
}

console.log(printQuantity(anOrderQtyInUnits)); // "10 units"
console.log(printQuantity(anOrderQtyInKg));    // "2.5 kg"

• 참고: TypeScript에는 F#의 match 같은 전용 패턴 매칭 문법은 없지만, 판별 필드(kind)를 갖는 유니온 타입에 switch를 사용하면 컴파일러가 각 case 안에서 타입을 자동으로 좁혀주므로(narrowing) 유사한 안전성을 얻을 수 있음

4.5 타입으로 도메인 모델 만들기

• 합성 가능한 타입 시스템은 도메인 주도 설계에 큰 도움이 됨. 타입들을 다양한 조합으로 섞기만 해도 빠르게 복잡한 모델을 만들 수 있기 때문
• 예시 시나리오: 이커머스 사이트의 결제(payment)를 추적하고 싶다고 가정하고, 설계 세션에서 코드가 어떻게 스케치되는지 확인

1) 원시 타입의 래퍼(= 단순 타입)부터 시작

type CheckNumber = CheckNumber of int
type CardNumber = CardNumber of string

type CheckNumber = { kind: "CheckNumber"; value: number };
type CardNumber = { kind: "CardNumber"; value: string };

• 의미 있는 이름을 부여함으로써 이후 도메인을 훨씬 이해하기 쉽게 만들어줌

2) 저수준 타입 구성

• CardType은 OR 타입(Visa 또는 Mastercard), CreditCardInfo는 AND 타입(레코드)

type CardType =
  Visa | Mastercard // 'OR' type

type CreditCardInfo = { // 'AND' type (record)
  CardType : CardType
  CardNumber : CardNumber
}

type CardType = "Visa" | "Mastercard"; // OR 타입

type CreditCardInfo = { // AND 타입 (레코드)
  cardType: CardType;
  cardNumber: CardNumber;
};

3) PaymentMethod: Cash, Check, Card 중 하나를 선택하는 OR 타입

• 단순한 “enum”이 아님. 일부 선택지는 연관 데이터를 가짐 — Check 케이스는 CheckNumber를, Card 케이스는 CreditCardInfo를 가짐

type PaymentMethod =
  | Cash
  | Check of CheckNumber
  | Card of CreditCardInfo

type PaymentMethod =
  | { kind: "Cash" }
  | { kind: "Check"; value: CheckNumber }
  | { kind: "Card"; value: CreditCardInfo };

4) 그 밖의 기본 타입

type PaymentAmount = PaymentAmount of decimal
type Currency = EUR | USD

type PaymentAmount = { kind: "PaymentAmount"; value: number };
type Currency = "EUR" | "USD";

5) 최상위 타입 Payment: PaymentAmount, Currency, PaymentMethod를 모두 가진 레코드

type Payment = {
  Amount : PaymentAmount
  Currency: Currency
  Method: PaymentMethod
}

type Payment = {
  amount: PaymentAmount;
  currency: Currency;
  method: PaymentMethod;
};

• 약 25줄의 코드만으로 꽤 쓸모 있는 타입 집합을 이미 정의한 것

graph TD
    Payment --> Amount[PaymentAmount]
    Payment --> Currency
    Payment --> Method[PaymentMethod]
    Method --> Cash
    Method --> Check --> CheckNumber
    Method --> Card --> CreditCardInfo
    CreditCardInfo --> CardType
    CreditCardInfo --> CardNumber

함수를 표현하는 타입으로 동작(behavior) 문서화하기

• 이 타입들에는 어떤 동작도 직접 결합되어 있지 않음. 함수형 모델이지 객체지향 모델이 아니기 때문
• 취할 수 있는 행동을 문서화하려면, 대신 함수를 나타내는 타입을 정의함
• 예: Payment를 이용해 미결제 인보이스(UnpaidInvoice)를 결제하고, 최종적으로 결제 완료된 인보이스(PaidInvoice)를 만드는 방법이 있다는 것을 보여주고 싶다면

type PayInvoice =
  UnpaidInvoice -> Payment -> PaidInvoice

type PayInvoice = (
  unpaidInvoice: UnpaidInvoice,
  payment: Payment
) => PaidInvoice;

• 의미: UnpaidInvoice와 Payment가 주어지면, PaidInvoice를 만들 수 있다
• 또 다른 예: 결제를 한 통화에서 다른 통화로 변환하는 경우

type ConvertPaymentCurrency =
  Payment -> Currency -> Payment

type ConvertPaymentCurrency = (
  payment: Payment,
  currency: Currency
) => Payment;

• 첫 번째 Payment는 입력, 두 번째 파라미터(Currency)는 변환할 대상 통화, 두 번째 Payment(출력)는 변환 후 결과

4.6 없어도 되는 값, 오류 및 컬렉션 모델링

• 지금까지 사용한 레코드와 선택 타입은 F#에서 null이 될 수 없음 → 도메인 모델에서 어떤 타입을 참조하든, 그것은 항상 필수값임
• 그렇다면 다음과 같은 상황은 F# 타입 시스템으로 어떻게 표현할 것인가
  • 없어도 되는 값(선택적/누락 값)
  • 오류
  • 아무 값도 반환하지 않는 함수
  • 컬렉션

4.6.1 없어도 되는 값 모델링

• 누락된 데이터가 의미하는 바를 생각해보면: 존재하거나(present) 부재하거나(absent) 둘 중 하나. 무언가 있거나, 아무것도 없거나
• 이를 Option이라는 선택 타입으로 모델링

type Option<'a> =
  | Some of 'a
  | None

flowchart TD
    O["Option&lt;'a&gt;"] --> S["Some 'a<br/>(값이 있음)"]
    O --> N["None<br/>(값이 없음)"]

• Some 케이스는 연관 값 'a에 데이터가 저장되어 있음을 의미
• None 케이스는 데이터가 없음을 의미
• 'a의 작은따옴표는 F#에서 제네릭 타입을 나타내는 표기법 — 즉 Option은 어떤 타입이든 감쌀 수 있음(C#/Java의 Option<T>에 해당)
• Option 타입은 F# 표준 라이브러리에 이미 정의되어 있으며, 함께 사용할 수 있는 다양한 헬퍼 함수도 풍부하게 제공됨
• 도메인 모델에서 선택적 데이터를 표시하려면 C#이나 Java에서처럼 타입을 Option<..>으로 감싸면 됨. 예: PersonalName 타입에서 이름(First)과 성(Last)은 필수지만 중간 이니셜(MiddleInitial)은 선택적인 경우

type PersonalName = {
  FirstName : string
  MiddleInitial: Option<string> // optional
  LastName : string
  }

• F#은 타입 뒤에 option 라벨을 붙이는 방식도 지원하며, 더 읽기 쉽고 실무에서 더 흔히 사용됨

type PersonalName = {
  FirstName : string
  MiddleInitial: string option
  LastName : string
  }

// 일반적인 TypeScript 방식: 선택적 필드(undefined 허용)
type PersonalName = {
  firstName: string;
  middleInitial?: string; // optional
  lastName: string;
};

// F#의 Option 스타일을 명시적으로 재현하고 싶다면
type Option<T> = { kind: "Some"; value: T } | { kind: "None" };

type PersonalNameExplicit = {
  firstName: string;
  middleInitial: Option<string>;
  lastName: string;
};

4.6.2 오류 모델링

• 예시 상황: “결제가 성공적으로 이루어졌거나, 카드가 만료되어 실패했다.” 이를 어떻게 모델링할 것인가?
• F#은 예외(exception)를 던지는 것도 지원하지만, 실패할 수 있다는 사실을 타입 시그니처에 명시적으로 문서화하고 싶은 경우가 많음
• 이는 두 가지 케이스를 가진 선택 타입을 요구함 → Result 타입 정의

type Result<'Success,'Failure> =
  | Ok of 'Success
  | Error of 'Failure

flowchart TD
    R["Result&lt;'Success,'Failure&gt;"] --> OK["Ok 'Success<br/>(성공)"]
    R --> ER["Error 'Failure<br/>(실패)"]

• Ok 케이스는 함수가 성공했을 때의 값을 담고, Error 케이스는 함수가 실패했을 때의 오류 데이터를 담음
• 어떤 종류의 데이터든 담을 수 있어야 하므로 정의에 제네릭 타입을 사용

F# 4.1 이상(또는 Visual Studio 2017 이상)을 사용한다면 Result 타입을 직접 정의할 필요가 없음 — 표준 F# 라이브러리에 이미 포함되어 있기 때문. 그 이전 버전의 F#을 사용한다면 몇 줄의 코드로 이 타입과 헬퍼 함수를 손쉽게 직접 정의할 수 있음

• 함수가 실패할 수 있음을 나타내려면 출력 타입을 Result로 감쌈. 예를 들어 PayInvoice 함수가 실패할 수 있다면

type PayInvoice =
  UnpaidInvoice -> Payment -> Result<PaidInvoice,PaymentError>

• Ok 케이스에 연관된 타입은 PaidInvoice, Error 케이스에 연관된 타입은 PaymentError. PaymentError는 가능한 각 오류에 대한 케이스를 가진 선택 타입으로 정의할 수 있음

type PaymentError =
  | CardTypeNotRecognized
  | PaymentRejected
  | PaymentProviderOffline

type Result<TSuccess, TFailure> =
  | { kind: "Ok"; value: TSuccess }
  | { kind: "Error"; error: TFailure };

type PaymentError =
  | "CardTypeNotRecognized"
  | "PaymentRejected"
  | "PaymentProviderOffline";

type PayInvoice = (
  unpaidInvoice: UnpaidInvoice,
  payment: Payment
) => Result<PaidInvoice, PaymentError>;

• 오류를 문서화하는 이 접근법은 10장(오류 다루기)에서 상세히 다룸

4.6.3 값 자체가 없음 모델링

• 대부분의 프로그래밍 언어에는 함수/메서드가 아무것도 반환하지 않을 때 쓰는 void 개념이 있음
• F# 같은 함수형 언어에서는 모든 함수가 반드시 무언가를 반환해야 하므로 void를 사용할 수 없음. 대신 unit이라는 특수한 내장 타입을 사용함
• unit의 값은 오직 하나이며, 괄호 쌍 ()로 표기함
• 예: 고객 레코드를 데이터베이스에 업데이트하는 함수 — 입력은 고객 레코드이지만 쓸모 있는 출력이 없는 경우, 출력 타입으로 unit을 사용

type SaveCustomer = Customer -> unit

• 반대로 입력은 없지만 쓸모 있는 값을 반환하는 함수(예: 난수를 생성하는 함수)도 “입력 없음”을 unit으로 나타냄

type NextRandom = unit -> int

type SaveCustomer = (customer: Customer) => void;

type NextRandom = () => number;

• 시그니처에서 unit 타입을 보게 되면, 그것은 부수효과(side effect)가 존재한다는 강력한 신호임. 어딘가에서 상태가 변경되고 있지만 그것이 숨겨져 있다는 뜻
• 일반적으로 함수형 프로그래머는 부수효과를 피하거나, 최소한 코드의 제한된 영역으로 국한시키려고 노력함
• 참고: TypeScript/JavaScript에는 이미 void, undefined 개념이 있어 F#만큼 “부수효과 신호”로서 엄격하게 구분되어 사용되지는 않음

4.6.4 리스트 및 컬렉션 모델링

• F#은 표준 라이브러리에서 다양한 컬렉션 타입을 지원함

• 도메인 모델링에서는 항상 list 타입을 사용하는 것을 권장함. option과 마찬가지로 타입 뒤에 접미사로 붙일 수 있어 가독성이 좋음

type Order = {
  OrderId : OrderId
  Lines : OrderLine list // a collection
}

type Order = {
  orderId: OrderId;
  lines: OrderLine[]; // 컬렉션
};

• 리스트 생성: 대괄호와 세미콜론(콤마 아님!)으로 구분하는 리스트 리터럴 사용

let aList = [1; 2; 3]

• 또는 ::(콘스, cons) 연산자로 기존 리스트 앞에 값을 붙여 새 리스트를 만들 수 있음

let aNewList = 0 :: aList // new list is [0;1;2;3]

const aList = [1, 2, 3];
const aNewList = [0, ...aList]; // [0, 1, 2, 3]

• 리스트 안의 요소에 접근하기 위해 리스트를 해체할 때도 유사한 패턴을 사용함
• 리스트 리터럴에 대한 패턴 매칭

let printList1 aList =
  // matching against list literals
  match aList with
  | [] ->
      printfn "list is empty"
  | [x] ->
      printfn "list has one element: %A" x
  | [x;y] -> // match using list literal
      printfn "list has two elements: %A and %A" x y
  | longerList -> // match anything else
      printfn "list has more than two elements"

• ::(cons) 연산자를 이용한 패턴 매칭

let printList2 aList =
  // matching against "cons"
  match aList with
  | [] ->
      printfn "list is empty"
  | first::rest ->
      printfn "list is non-empty with the first element being: %A" first

function printList1(aList: number[]): string {
  if (aList.length === 0) return "list is empty";
  if (aList.length === 1) return `list has one element: ${aList[0]}`;
  if (aList.length === 2)
    return `list has two elements: ${aList[0]} and ${aList[1]}`;
  return "list has more than two elements";
}

function printList2(aList: number[]): string {
  const [first, ...rest] = aList;
  if (first === undefined) return "list is empty";
  return `list is non-empty with the first element being: ${first}`;
}

• 참고: TypeScript에는 F#의 match처럼 리스트 구조 자체에 대한 전용 패턴 매칭 문법이 없으므로, 길이 검사나 구조 분해 할당(destructuring)으로 유사한 동작을 재현함

4.7 마무리

타입을 파일과 프로젝트에서 구성하기

• F#은 선언 순서에 엄격한 규칙을 둠
  • 파일 위쪽에 있는 타입은 그보다 아래쪽에 있는 타입을 참조할 수 없음
  • 컴파일 순서상 앞선 파일은 그보다 뒤에 있는 파일을 참조할 수 없음
  • 즉, 타입을 코딩할 때 이들을 어떻게 조직할지 반드시 고려해야 함
• 표준적인 접근법
  • 모든 도메인 타입을 하나의 파일(예: Types.fs 또는 Domain.fs)에 모으고
  • 그 타입에 의존하는 함수들은 컴파일 순서상 이후에 배치
  • 타입이 많아 여러 파일로 나눠야 한다면, 공유 타입을 먼저, 하위 도메인별 타입을 그 다음 순서로 배치

Common.Types.fs
Common.Functions.fs
OrderTaking.Types.fs
OrderTaking.Functions.fs
Shipping.Types.fs
Shipping.Functions.fs

flowchart TD
    A[Common.Types.fs] --> B[Common.Functions.fs]
    B --> C[OrderTaking.Types.fs]
    C --> D[OrderTaking.Functions.fs]
    D --> E[Shipping.Types.fs]
    E --> F[Shipping.Functions.fs]

• 한 파일 안에서도, 이 규칙 때문에 단순한 타입은 파일 위쪽에, 그것에 의존하는 더 복잡한 타입은 그 아래쪽에 의존성 순서대로 배치해야 함

module Payments =
  // simple types at the top of the file
  type CheckNumber = CheckNumber of int

  // domain types in the middle of the file
  type PaymentMethod =
    | Cash
    | Check of CheckNumber // defined above
    | Card of ...

  // top-level types at the bottom of the file
  type Payment = {
    Amount: ...
    Currency: ...
    Method: PaymentMethod // defined above
  }

• 모델을 위에서 아래로(top-down) 설계할 때는, 상위 타입 아래에 하위 타입을 쓰고 싶은 경우가 많아 이 제약이 불편할 수 있음
• F# 4.1부터는 모듈(또는 네임스페이스) 레벨에서 rec 키워드를 사용해 이를 해결할 수 있음. rec 키워드는 모듈 내부에서 타입들이 어느 위치에 있든 서로를 참조할 수 있게 해줌

module rec Payments =
  type Payment = {
    Amount: ...
    Currency: ...
    Method: PaymentMethod // defined BELOW
  }

  type PaymentMethod =
    | Cash
    | Check of CheckNumber // defined BELOW
    | Card of ...

  type CheckNumber = CheckNumber of int

• 이전 버전의 F#에서는 and 키워드를 사용해, 타입 정의가 바로 아래에 있는 타입을 참조하도록 허용할 수 있음

type Payment = {
  Amount: ...
  Currency: ...
  Method: PaymentMethod // defined BELOW
}
and PaymentMethod =
  | Cash
  | Check of CheckNumber // defined BELOW
  | Card of ...
and CheckNumber = CheckNumber of int

• 이런 순서 무관 방식은 스케치(설계 초안) 단계에서는 유용하지만, 설계가 확정되어 프로덕션에 들어갈 준비가 되면 일반적으로 타입을 올바른 의존성 순서에 맞게 정리하는 편이 더 좋음. 다른 F# 코드와의 일관성을 유지할 수 있고, 다른 개발자가 읽기에도 더 쉬워지기 때문
• 실제 프로젝트에서 타입을 어떻게 조직하는지에 대한 실전 예시는 이 책의 코드 저장소에서 확인 가능(원문 기준)

챕터 정리(Wrapping Up)

• 이번 장에서 다룬 내용
  • 타입(type)의 개념과, 그것이 함수형 프로그래밍과 어떻게 관련되는지
  • F#의 대수적 타입 시스템을 이용해, 작은 타입을 합성함으로써 더 큰 타입을 만드는 방법
  • AND로 데이터를 결합해 만드는 레코드(record) 타입
  • OR로 데이터를 결합해 만드는 선택(choice) 타입(= 판별 유니온)
  • 이런 기본 개념 위에 세워진 Option, Result 같은 공통 타입들
• 이제 타입이 어떻게 동작하는지 이해했으므로, 앞서 정리했던 요구사항을 다시 살펴보고 지금까지 배운 내용을 이용해 그것을 문서화할 준비가 됨(→ 5장으로 이어짐)

핵심 개념 요약표

챕터 5 타입으로 도메인 모델링하기

이 챕터의 핵심 문제의식

• 1장에서 강조한 “공유된 멘탈 모델”을 소스 코드 자체가 반영해야 함
• 개발자가 도메인 모델과 소스 코드 사이에서 손실 있는 번역(lossy translation)을 하지 않아야 함
• 이상적으로는 소스 코드 자체가 문서 역할을 해서, 도메인 전문가나 비개발자도 코드를 리뷰하고 설계를 검토할 수 있어야 함
• 이 장의 목표: F# 타입 시스템으로 도메인 모델을 정확하게 담아내면서도, 비개발자가 읽고 이해할 수 있는 수준으로 표현하는 방법을 학습
• 핵심 인사이트: ==타입이 대부분의 문서를 대체할 수 있음== → 설계가 곧 코드이므로 구현이 설계와 어긋나는 일이 근본적으로 불가능해짐

5.1 도메인 모델 다시 보기

• 이전 장(원서 36페이지)에서 작성한 Order-Taking 컨텍스트의 도메인 모델을 다시 검토하는 절
• 이 모델은 AND/OR 표기법을 사용한 의사코드(pseudo-code) 형태
• 구성 요소
  • 단순 타입: ProductCode(WidgetCode OR GizmoCode), OrderQuantity(UnitQuantity OR KilogramQuantity)
  • 주문 생명주기 상태: 미검증(UnvalidatedOrder) → 검증됨(ValidatedOrder) → 가격산정됨(PricedOrder)
  • 출력 이벤트: OrderAcknowledgmentSent, OrderPlaced, BillableOrderPlaced
  • 워크플로우: "Place Order" — 입력/출력/에러가 명시된 비즈니스 프로세스

context: Order-Taking

// 단순 타입
data ProductCode = WidgetCode OR GizmoCode
data WidgetCode = string starting with "W" then 4 digits
data GizmoCode = ...

data OrderQuantity = UnitQuantity OR KilogramQuantity
data UnitQuantity = ...
data KilogramQuantity = ...

// 주문 생명주기
// ----- 미검증 상태 -----
data UnvalidatedOrder =
    UnvalidatedCustomerInfo
    AND UnvalidatedShippingAddress
    AND UnvalidatedBillingAddress
    AND list of UnvalidatedOrderLine

data UnvalidatedOrderLine =
    UnvalidatedProductCode
    AND UnvalidatedOrderQuantity

// ----- 검증됨 상태 -----
data ValidatedOrder = ...
data ValidatedOrderLine = ...

// ----- 가격산정됨 상태 -----
data PricedOrder = ...
data PricedOrderLine = ...

// ----- 출력 이벤트 -----
data OrderAcknowledgmentSent = ...
data OrderPlaced = ...
data BillableOrderPlaced = ...

// 워크플로우
workflow "Place Order" =
    input: UnvalidatedOrder
    output (성공 시):
        OrderAcknowledgmentSent
        AND OrderPlaced (배송팀 전달용)
        AND BillableOrderPlaced (청구팀 전달용)
    output (실패 시):
        InvalidOrder

• 이 장의 목표: 위 의사코드 모델을 실제 F# 코드로 옮기는 것

5.2 도메인 모델 속 패턴 찾기

• 도메인마다 세부 내용은 다르지만, 반복적으로 나타나는 패턴이 존재
• 4가지 패턴
  • 단순값(Simple values): string, int 같은 원시 타입으로 표현되는 기본 빌딩 블록. 단, 도메인 전문가는 int/string이 아니라 OrderId, ProductCode 같은 유비쿼터스 언어(ubiquitous language) 개념으로 사고함
  • AND로 조합된 값: 밀접하게 연관된 데이터 그룹. 종이 기반 업무에서는 보통 문서나 하위 구성요소(이름, 주소, 주문 등)에 대응
  • OR로 선택되는 값: 도메인에서 나타나는 선택지. 예: 주문(Order) 또는 견적(Quote), 개수 단위(UnitQuantity) 또는 킬로그램 단위(KilogramQuantity)
  • 워크플로우: 입력과 출력이 있는 비즈니스 프로세스

flowchart TD
    A[도메인 모델의 4가지 패턴] --> B[단순값]
    A --> C["AND 조합"]
    A --> D["OR 선택"]
    A --> E[워크플로우]
    B --> B1["OrderId, ProductCode 등<br/>기본 빌딩 블록"]
    C --> C1["레코드 형태<br/>예: 이름, 주소, 주문"]
    D --> D1["선택 가능한 대안<br/>예: Order vs Quote"]
    E --> E1["입력-처리-출력<br/>비즈니스 프로세스"]

• 이후 절에서 F# 타입으로 이 4가지 패턴을 각각 어떻게 표현하는지 다룸

5.3 단순값 모델링

• 도메인의 가장 기본적인 빌딩 블록인 단순값부터 다룸
• 도메인 전문가는 int, string이 아니라 OrderId, ProductCode 같은 도메인 개념으로 사고함
• OrderId와 ProductCode는 둘 다 내부적으로 int/string일 수 있지만, 서로 뒤섞이면 안 됨 → 구별되는 타입임을 명확히 하기 위해 “래퍼 타입(wrapper type)“을 만듦
• F#에서 래퍼 타입을 만드는 가장 쉬운 방법: “단일 케이스 유니온(single-case union)” — 케이스가 하나뿐인 선택 타입

type CustomerId =
    | CustomerId of int

• 케이스가 하나뿐이므로 보통 한 줄로 작성

type CustomerId = CustomerId of int

• 이런 래퍼 타입을 복합 타입(레코드)이나 원시 타입(string, int)과 구분해 “단순 타입(simple type)“이라 부름
• 도메인의 단순 타입 예시

type WidgetCode = WidgetCode of string
type UnitQuantity = UnitQuantity of int
type KilogramQuantity = KilogramQuantity of decimal

• 단일 케이스 유니온 정의의 두 부분: 타입 이름 + 케이스 레이블

type CustomerId = CustomerId of int
//      ^타입 이름   ^케이스 레이블

• 관례상 케이스 레이블은 타입 이름과 동일하게 짓는 경우가 많음 → 생성/해체 시 같은 이름을 재사용 가능

TypeScript 대응 (브랜드 타입 패턴)

• TS에는 F#의 구별된 유니온과 동일한 개념이 없으므로, 원시 타입에 “브랜드(brand)“를 붙여 명목적 타입(nominal type)처럼 흉내내는 방식을 사용함

// 브랜드를 이용해 number를 CustomerId라는 구별된 타입으로 취급
type CustomerId = number & { readonly __brand: "CustomerId" };

// 생성자 함수
const CustomerId = (value: number): CustomerId => value as CustomerId;

type WidgetCode = string & { readonly __brand: "WidgetCode" };
type UnitQuantity = number & { readonly __brand: "UnitQuantity" };
type KilogramQuantity = number & { readonly __brand: "KilogramQuantity" };

5.3.1 래퍼 타입 활용하기

• 단순 타입의 값을 생성할 때는 케이스 이름을 생성자 함수처럼 사용

type CustomerId = CustomerId of int
// ^ 이 케이스 이름이 생성자 함수가 됨

let customerId = CustomerId 42
// ^ int 하나를 매개변수로 받는 함수

• 이렇게 만든 단순 타입 덕분에 서로 다른 타입을 실수로 혼동하는 것을 방지할 수 있음. CustomerId와 OrderId를 비교하면 컴파일 에러 발생

type CustomerId = CustomerId of int
type OrderId = OrderId of int

let customerId = CustomerId 42
let orderId = OrderId 42

// 비교 시도 -- 컴파일 에러!
printfn "%b" (orderId = customerId)
// ^ 'OrderId' 타입이 기대되었으나 'CustomerId'가 사용됨

• CustomerId를 입력으로 받는 함수에 OrderId를 넘기는 것도 컴파일 에러

let processCustomerId (id: CustomerId) = ...

processCustomerId orderId
// ^ 컴파일 에러: 'CustomerId' 타입이 기대되었으나 'OrderId'가 사용됨

• 단일 케이스 유니온을 해체(deconstruct)/언래핑할 때는 케이스 레이블로 패턴 매칭

// 생성
let customerId = CustomerId 42

// 해체
let (CustomerId innerValue) = customerId
// ^ innerValue는 42

printfn "%i" innerValue // "42" 출력

• 함수 매개변수 자리에서 바로 해체하는 것이 흔한 관용구임 → 내부 값에 즉시 접근 가능 + 컴파일러가 타입을 자동 추론

let processCustomerId (CustomerId innerValue) =
    printfn "innerValue is %i" innerValue

// 함수 시그니처: val processCustomerId: CustomerId -> unit

TypeScript 대응

// 생성
const customerId = CustomerId(42);
const orderId = OrderId(42);

// orderId === customerId;
// 컴파일 에러: Type 'OrderId' is not comparable to type 'CustomerId'

function processCustomerId(id: CustomerId): void {
  console.log(`inner value: ${id}`);
}

// processCustomerId(orderId);
// 컴파일 에러: Argument of type 'OrderId' is not assignable to
// parameter of type 'CustomerId'

// 해체(언래핑): 브랜드 타입은 런타임에는 원시값 그대로이므로
// 별도 구문 없이 값을 그대로 쓰거나 명시적으로 캐스팅
function unwrapCustomerId(id: CustomerId): number {
  return id as number;
}

// 함수 매개변수에서 바로 활용
function processCustomerId2(id: CustomerId): void {
  const innerValue = id as number;
  console.log(`innerValue is ${innerValue}`);
}

참고: F#의 래퍼 타입은 런타임에도 실제로 값을 감싸는 별도 객체이지만, TS 브랜드 타입은 컴파일 타임에만 존재하고 런타임에는 원시값 그대로임(오버헤드 없음) — 타입 안전성의 성격이 다소 다름

5.3.2 제약 있는 값

• 실무 도메인에서는 단순 타입에 거의 항상 제약(constraint)이 있음
  • 예: 특정 범위 안에 있어야 함, 특정 패턴과 일치해야 함
• 실전 도메인에서 아무 제약 없는 정수/문자열은 매우 드묾
• 이러한 제약을 어떻게 강제할지는 다음 장(“단순 값의 무결성”, 원서 104페이지)에서 다룸 → 이 절 자체는 문제 제기만 하고 넘어감

5.3.3 단순 타입의 성능 문제 완화하기

• 원시 타입을 단순 타입으로 감싸는 것은 타입 안전성 확보에 매우 유용하지만, 메모리 사용량과 효율 측면에서 비용이 발생함
• 일반적인 업무 애플리케이션에서는 약간의 성능 저하가 문제되지 않지만, 과학 계산이나 실시간 처리처럼 고성능이 필요한 도메인에서는 주의가 필요함
• 예: UnitQuantity 배열을 순회하는 것은 원시 int 배열을 순회하는 것보다 느림
• 해결책 3가지

방법 1: 타입 별칭(type alias) 사용 — 오버헤드는 없지만 타입 안전성을 잃음

type UnitQuantity = int

방법 2: 값 타입(struct) 사용 — F# 4.1부터 가능, 배열에 저장 시 메모리가 연속적으로 배치되어 캐시 친화적

[<Struct>]
type UnitQuantity = UnitQuantity of int

방법 3: 원시값 컬렉션 전체를 하나의 타입으로 정의 — 대량 배열을 다룰 때 유리

type UnitQuantities = UnitQuantities of int[]

• 이 방법을 확장하면 데이터 지향 설계(data-oriented design)로 이어짐 (게임 개발에서 흔히 사용)
• 유비쿼터스 언어에 이런 컬렉션을 가리키는 단어(예: “DataSample”, “Measurements”)가 있다면 그 단어를 그대로 사용할 것
• 원칙: 성능은 복잡한 주제이므로, 우선 도메인을 가장 직관적인 방식으로 모델링하고 이후에 튜닝/최적화를 진행할 것

TypeScript 대응

// 방법 1: 타입 별칭 (런타임 오버헤드 없음, 타입 안전성 없음)
type UnitQuantityAlias = number;

// 방법 2: 브랜드 타입 (컴파일 타임 안전성, 런타임엔 원시값과 동일)
type UnitQuantity = number & { readonly __brand: "UnitQuantity" };

// 방법 3: 대량 컬렉션을 하나의 타입으로 묶기
type UnitQuantities = number[] & { readonly __brand: "UnitQuantities" };

참고: TS 브랜드 타입은 애초에 런타임 표현이 원시값과 동일하므로, F#과 달리 “성능 완화”라는 고민 자체가 크게 필요하지 않음

5.4 복잡한 데이터 모델링

• 앞서 도메인을 문서화할 때 AND/OR로 복잡한 모델을 표현함
• F#의 대수적 타입 시스템(algebraic type system) 역시 AND/OR로 복합 타입을 만듦
• 따라서 이 대수적 타입 시스템을 그대로 도메인 모델링에 적용할 수 있음

5.4.1 레코드 모델링

• 도메인의 많은 데이터 구조는 AND 관계로 이루어짐
• 예: 단순화한 Order

data Order =
    CustomerInfo
    AND ShippingAddress
    AND BillingAddress
    AND list of OrderLines
    AND AmountToBill

• 이는 F# 레코드 구조로 바로 대응됨

type Order = {
    CustomerInfo : CustomerInfo
    ShippingAddress : ShippingAddress
    BillingAddress : BillingAddress
    OrderLines : OrderLine list
    AmountToBill : ...
}

• 각 필드에 이름(“CustomerInfo”, “ShippingAddress”)과 타입(CustomerInfo, ShippingAddress)을 부여함
• 이렇게 작성해보면 아직 풀리지 않은 질문들이 드러남
  • ShippingAddress와 BillingAddress는 같은 타입인가?
  • AmountToBill은 어떤 타입으로 표현해야 하는가?
• 이런 질문은 도메인 전문가와 함께 풀어야 함. 청구지 주소와 배송지 주소를 전문가가 서로 다른 개념으로 이야기한다면, 구조가 같더라도 논리적으로 분리해두는 것이 좋음(요구사항 변화에 따라 서로 다른 방향으로 진화할 수 있음)

TypeScript 대응

interface Order {
  customerInfo: CustomerInfo;
  shippingAddress: ShippingAddress;
  billingAddress: BillingAddress;
  orderLines: OrderLine[];
  amountToBill: BillingAmount; // 타입 아직 미정
}

5.4.2 잘 모르는 타입 모델링

• 설계 초기 단계에서는 유비쿼터스 언어 덕분에 타입 이름은 알지만, 내부 구조는 아직 모를 때가 많음
• 문제 없음 — 최선의 추측으로 표현하거나, 아직 정의되지 않았음을 명시하는 “플레이스홀더” 타입으로 표현하면 됨
• F#에서는 예외 타입 exn을 Undefined로 별칭 지정해서 사용

type Undefined = exn

• 이 별칭을 설계 모델 전체에 적용

type CustomerInfo = Undefined
type ShippingAddress = Undefined
type BillingAddress = Undefined
type OrderLine = Undefined
type BillingAmount = Undefined

type Order = {
    CustomerInfo : CustomerInfo
    ShippingAddress : ShippingAddress
    BillingAddress : BillingAddress
    OrderLines : OrderLine list
    AmountToBill : BillingAmount
}

• 이 방식의 장점: 도메인을 타입으로 계속 모델링하면서 컴파일까지 가능함. 단, 실제로 해당 타입을 처리하는 함수를 작성하려는 순간 Undefined를 더 나은 것으로 교체하도록 강제됨

TypeScript 대응

type Undefined = unknown; // 아직 구조가 정해지지 않은 타입의 자리표시자

type CustomerInfo = Undefined;
type ShippingAddress = Undefined;
type BillingAddress = Undefined;
type OrderLine = Undefined;
type BillingAmount = Undefined;

interface Order {
  customerInfo: CustomerInfo;
  shippingAddress: ShippingAddress;
  billingAddress: BillingAddress;
  orderLines: OrderLine[];
  amountToBill: BillingAmount;
}

5.4.3 선택 타입 모델링

• 도메인에는 다른 것들 사이의 “선택”인 경우도 많음

data ProductCode =
    WidgetCode
    OR GizmoCode

data OrderQuantity =
    UnitQuantity
    OR KilogramQuantity

• F#의 선택 타입(구별된 유니온)으로 이를 표현

type ProductCode =
    | Widget of WidgetCode
    | Gizmo of GizmoCode

type OrderQuantity =
    | Unit of UnitQuantity
    | Kilogram of KilogramQuantity

• 각 케이스는 “태그(케이스 레이블)“와 그 케이스에 연결된 데이터 타입, 두 부분으로 구성됨
• 케이스 레이블(예: Widget)이 연결된 타입 이름(WidgetCode)과 반드시 같을 필요는 없음

TypeScript 대응 (구별된 유니온)

type ProductCode =
  | { kind: "Widget"; value: WidgetCode }
  | { kind: "Gizmo"; value: GizmoCode };

type OrderQuantity =
  | { kind: "Unit"; value: UnitQuantity }
  | { kind: "Kilogram"; value: KilogramQuantity };

5.5 함수로 작업 흐름 모델링하기

• 지금까지는 모든 데이터 구조, 즉 유비쿼터스 언어의 “명사”를 모델링하는 방법을 다룸
• 이제 “동사”, 즉 비즈니스 프로세스를 다룰 차례
• 이 책에서는 워크플로우와 기타 프로세스를 함수 타입으로 모델링함
• 예: 주문 양식을 검증하는 워크플로우 단계

type ValidateOrder = UnvalidatedOrder -> ValidatedOrder

• 이 코드만으로 ValidateOrder 프로세스가 미검증 주문을 검증된 주문으로 변환한다는 것이 명확히 드러남

TypeScript 대응

type ValidateOrder = (order: UnvalidatedOrder) => ValidatedOrder;

5.5.1 복잡한 입력 및 출력 처리

• 모든 함수는 입력과 출력이 하나씩이지만, 실제 워크플로우는 입출력이 여러 개일 수 있음

출력이 여러 개(AND)인 경우 → 레코드 타입으로 묶음

• 주문 처리 워크플로우는 3개의 서로 다른 이벤트를 출력해야 하므로, 하나의 레코드로 묶어서 표현

type PlaceOrderEvents = {
    AcknowledgmentSent : AcknowledgmentSent
    OrderPlaced : OrderPlaced
    BillableOrderPlaced : BillableOrderPlaced
}

type PlaceOrder = UnvalidatedOrder -> PlaceOrderEvents

출력이 여러 개(OR)인 경우 → 선택 타입으로 묶음

• 수신 메일을 견적/주문으로 분류하는 프로세스 예시

workflow "Categorize Inbound Mail" =
    input: Envelope contents
    output:
        QuoteForm (해당 더미에 배치)
        OR OrderForm (해당 더미에 배치)
        OR ...

type EnvelopeContents = EnvelopeContents of string

type CategorizedMail =
    | Quote of QuoteForm
    | Order of OrderForm
    // etc

type CategorizeInboundMail = EnvelopeContents -> CategorizedMail

입력이 여러 개(AND, 모두 필수)인 경우 → 두 가지 접근법

"Calculate Prices" =
    input: OrderForm, ProductCatalog
    output: PricedOrder

• 접근법 1: 각 입력을 별도의 매개변수로 전달(가장 단순함)

type CalculatePrices = OrderForm -> ProductCatalog -> PricedOrder

• 접근법 2: 새 레코드 타입으로 두 입력을 함께 묶음

type CalculatePricesInput = {
    OrderForm : OrderForm
    ProductCatalog : ProductCatalog
}

type CalculatePrices = CalculatePricesInput -> PricedOrder

• 어느 쪽이 더 나은가?
  • ProductCatalog처럼 “진짜 입력”이라기보다 의존성(dependency)에 가까운 경우 → 별도 매개변수 방식을 사용 (함수형 의존성 주입에 해당, 원서 180페이지에서 상세히 다룸)
  • 두 입력이 항상 함께 필요하고 서로 강하게 연결되어 있다면 → 레코드 타입을 사용해 이를 명확히 드러냄 (튜플도 대안이 될 수 있으나, 대개 이름이 있는 타입이 더 나음)

flowchart LR
    In[UnvalidatedOrder] --> WF{{"PlaceOrder 워크플로우"}}
    WF -->|성공| S1[OrderAcknowledgmentSent]
    WF -->|성공| S2[OrderPlaced]
    WF -->|성공| S3[BillableOrderPlaced]
    WF -->|실패| Err[InvalidOrder]

TypeScript 대응

interface PlaceOrderEvents {
  acknowledgmentSent: AcknowledgmentSent;
  orderPlaced: OrderPlaced;
  billableOrderPlaced: BillableOrderPlaced;
}

type PlaceOrder = (order: UnvalidatedOrder) => PlaceOrderEvents;

type EnvelopeContents = string;

type CategorizedMail =
  | { kind: "Quote"; value: QuoteForm }
  | { kind: "Order"; value: OrderForm };

type CategorizeInboundMail = (contents: EnvelopeContents) => CategorizedMail;

// 접근법 1: 별도 매개변수(커링 스타일)
type CalculatePrices = (orderForm: OrderForm) => (catalog: ProductCatalog) => PricedOrder;

// 접근법 2: 입력 레코드로 묶기
interface CalculatePricesInput {
  orderForm: OrderForm;
  productCatalog: ProductCatalog;
}
type CalculatePrices2 = (input: CalculatePricesInput) => PricedOrder;

5.5.2 함수 시그니처에서 효과 문서화하기

• 앞선 ValidateOrder는 검증이 항상 성공한다고 가정했지만, 실제로는 그렇지 않음
• 실패 가능성을 표현하려면 함수 시그니처에 Result 타입(원서 70페이지에서 소개)을 반환하도록 함

type ValidateOrder =
    UnvalidatedOrder -> Result<ValidatedOrder, ValidationError list>

and ValidationError = {
    FieldName : string
    ErrorDescription : string
}

• 입력은 UnvalidatedOrder, 성공 시 출력은 ValidatedOrder, 실패 시 출력은 ValidationError 목록(필드명 + 에러 설명 포함)임이 시그니처에서 드러남
• 함수형 프로그래밍 용어로, 주요 출력 외에 함수가 추가로 수행하는 것을 “효과(effects)“라고 부름 → Result 사용으로 “에러 효과”가 있음을 문서화한 것
• 함수가 비동기(asynchronous)임을 표현하려면 Async 타입을 사용

type ValidateOrder =
    UnvalidatedOrder -> Async<Result<ValidatedOrder, ValidationError list>>

• 이 시그니처는 (a) 반환값을 가져오려 할 때 즉시 반환되지 않음, (b) 반환되었을 때 결과가 에러일 수 있음, 두 가지를 모두 문서화함
• 모든 효과를 나열하면 시그니처가 복잡해지므로 보통 타입 별칭으로 깔끔하게 정리함

type ValidationResponse<'a> = Async<Result<'a, ValidationError list>>

type ValidateOrder =
    UnvalidatedOrder -> ValidationResponse<ValidatedOrder>

flowchart TD
    F1["UnvalidatedOrder -> ValidatedOrder<br/>(순수 함수, 효과 없음)"] --> F2["Result 타입 추가<br/>(에러 효과)"]
    F2 --> F3["Async 타입 추가<br/>(비동기 효과)"]

TypeScript 대응

// Result 타입 정의 (F#의 Result<'T,'E>에 해당)
type Result<T, E> =
  | { ok: true; value: T }
  | { ok: false; error: E };

interface ValidationError {
  fieldName: string;
  errorDescription: string;
}

type ValidateOrder = (
  order: UnvalidatedOrder
) => Result<ValidatedOrder, ValidationError[]>;

// 비동기 효과 추가 (F#의 Async에 대응하는 Promise 사용)
type ValidateOrderAsync = (
  order: UnvalidatedOrder
) => Promise<Result<ValidatedOrder, ValidationError[]>>;

// 효과를 타입 별칭으로 정리
type ValidationResponse<A> = Promise<Result<A, ValidationError[]>>;

type ValidateOrderFinal = (order: UnvalidatedOrder) => ValidationResponse<ValidatedOrder>;

5.6 정체성에 관하여: 값 객체

• 도메인 타입을 모델링하는 기본기를 익혔으니, 이제 데이터가 “지속적인 정체성(persistent identity)“을 갖는지에 따라 타입을 분류하는 중요한 방법을 다룸
• DDD 용어
  • 지속적인 정체성을 가진 객체 = 엔터티(Entity)
  • 지속적인 정체성이 없는 객체 = 값 객체(Value Object)
• 값 객체부터 살펴봄: 많은 데이터 객체는 정체성이 없이 상호교환 가능함
  • 예: WidgetCode "W1234" 인스턴스 하나와 다른 인스턴스는 서로 같은 것으로 취급됨(어느 것이 어느 것인지 추적할 필요 없음)

let widgetCode1 = WidgetCode "W1234"
let widgetCode2 = WidgetCode "W1234"
printfn "%b" (widgetCode1 = widgetCode2) // "true" 출력

• 값 객체 개념은 복합 타입에서도 자주 나타남
• 예: PersonalName 레코드(FirstName, LastName 필드)도 두 값의 필드가 같으면 상호교환 가능한 값 객체임

let name1 = {FirstName="Alex"; LastName="Adams"}
let name2 = {FirstName="Alex"; LastName="Adams"}
printfn "%b" (name1 = name2) // "true" 출력

• 주소(address) 타입도 값 객체임 — 거리, 도시, 우편번호가 같으면 같은 주소로 취급

let address1 = {StreetAddress="123 Main St"; City="New York"; Zip="90001"}
let address2 = {StreetAddress="123 Main St"; City="New York"; Zip="90001"}
printfn "%b" (address1 = address2) // "true" 출력

• 자연어 표현으로 판별하는 팁: “Chris는 나와 이름이 같다”라고 말할 수 있다면 값 객체임 — Chris와 나는 다른 사람이지만 이름 자체는 같음(고유한 정체성이 없음). “Pat은 나와 우편주소가 같다”도 마찬가지

TypeScript 대응

const widgetCode1 = WidgetCode("W1234");
const widgetCode2 = WidgetCode("W1234");

// 브랜드 원시값이므로 참조가 아닌 값 비교가 그대로 동작함
console.log(widgetCode1 === widgetCode2); // true

interface PersonalName {
  firstName: string;
  lastName: string;
}

const name1: PersonalName = { firstName: "Alex", lastName: "Adams" };
const name2: PersonalName = { firstName: "Alex", lastName: "Adams" };

// 주의: 객체 리터럴은 참조 비교이므로 아래는 false
console.log(name1 === name2); // false

// 구조적 비교를 위한 헬퍼 필요
function shallowEqual<T extends object>(a: T, b: T): boolean {
  return JSON.stringify(a) === JSON.stringify(b);
}
console.log(shallowEqual(name1, name2)); // true

5.6.1 값 객체의 같음

• F#의 대수적 타입 시스템으로 만든 타입은 기본적으로 필드 기반 동등성(equality) 검사를 자동으로 구현함 → 별도의 동등성 코드를 작성할 필요 없음
• 정확한 규칙(구조적 동등성, structural equality)
  • 같은 타입의 두 레코드 값은 모든 필드가 같으면 같음
  • 두 선택 타입 값은 같은 케이스이고 그 케이스에 연결된 데이터도 같으면 같음

참고: TS/JS는 객체·클래스에 대해 기본적으로 참조 동등성(===)만 제공함 — F#처럼 필드 기반 구조적 동등성이 내장되어 있지 않으므로, 값 객체를 비교하려면 항상 별도의 비교 함수(예: JSON.stringify 비교, lodash.isEqual 등)가 필요함

5.7 정체성에 관하여: 엔터티

• 실제로는 구성요소가 바뀌어도 고유한 정체성을 유지해야 하는 것들을 모델링해야 할 때가 많음. 예: 내가 이름이나 주소를 바꿔도 나는 여전히 같은 사람임
• DDD 용어로 이런 것을 엔터티(Entity)라고 부름
• 비즈니스 맥락에서 엔터티는 대개 어떤 문서에 해당함: 주문, 견적, 청구서, 고객 프로필, 상품 시트 등 — 생명주기를 가지며 여러 비즈니스 프로세스에 의해 상태가 변함
• “값 객체” vs “엔터티” 구분은 맥락에 따라 달라짐
  • 휴대폰 예시
    • 제조 단계: 각 폰에 고유 시리얼 번호 부여 → 엔터티로 모델링
    • 판매 단계: 시리얼 번호가 중요하지 않음, 같은 스펙의 폰은 상호교환 가능 → 값 객체로 모델링
    • 특정 고객에게 판매된 이후: 정체성이 다시 중요해짐 → 엔터티로 모델링(화면·배터리를 교체해도 고객은 같은 폰으로 인식)

flowchart LR
    P1["제조 단계<br/>엔터티: 고유 시리얼번호"] --> P2["판매 단계<br/>값 객체: 스펙 동일하면 상호교환"]
    P2 --> P3["구매 후 소유 단계<br/>엔터티: 동일 전화기로 인식"]

5.7.1 엔터티의 ID

• 엔터티는 변화에도 불구하고 안정적인 정체성을 가져야 하므로, 모델링 시 고유 식별자(ID/키)를 부여해야 함. 예: “Order ID”, “Customer ID”
• 예: Contact 타입은 PhoneNumber나 EmailAddress가 바뀌어도 ContactId는 그대로 유지됨

type ContactId = ContactId of int

type Contact = {
    ContactId : ContactId
    PhoneNumber : ...
    EmailAddress: ...
}

• 식별자의 출처
  • 실제 도메인 자체에서 제공되는 경우: 종이 주문서/청구서에는 원래부터 참조번호가 적혀 있음
  • 인위적으로 만들어야 하는 경우: UUID, 자동 증가 DB 테이블, ID 생성 서비스 등 (이 책에서는 식별자가 클라이언트로부터 이미 제공된다고 가정하고 더 깊이 다루지 않음)

TypeScript 대응

type ContactId = number & { readonly __brand: "ContactId" };
const ContactId = (value: number): ContactId => value as ContactId;

interface Contact {
  contactId: ContactId;
  phoneNumber: PhoneNumber;
  emailAddress: EmailAddress;
}

5.7.2 데이터 정의에 ID 포함하기

• 어떤 도메인 객체를 엔터티로 판별했다면, 정의에 식별자를 어떻게 추가할까?
• 레코드 타입에 ID를 추가하는 것은 간단함(필드 하나 추가) — 문제는 선택 타입에 ID를 추가하는 방식
• 질문: ID를 선택 타입 “바깥”에 둘 것인가, 각 케이스 “안”에 둘 것인가?
• 예시: Invoice(청구서)를 완납/미납 두 케이스로 모델링

바깥쪽(outside) 접근법 — InvoiceId를 최상위 레코드에 두고, 그 안에 선택 타입 InvoiceInfo를 둠

// 미납 케이스 정보 (id 없음)
type UnpaidInvoiceInfo = ...
// 완납 케이스 정보 (id 없음)
type PaidInvoiceInfo = ...

// 결합된 정보 (id 없음)
type InvoiceInfo =
    | Unpaid of UnpaidInvoiceInfo
    | Paid of PaidInvoiceInfo

// 청구서 id
type InvoiceId = ...

// 최상위 청구서 타입
type Invoice = {
    InvoiceId : InvoiceId   // 두 하위 케이스 "바깥"에 위치
    InvoiceInfo : InvoiceInfo
}

• 이 접근법의 문제: 특정 케이스의 데이터를 다루려 할 때 데이터가 여러 컴포넌트에 흩어져 있어 다루기 불편함

안쪽(inside) 접근법 — 실무에서 더 흔히 사용됨, 각 케이스가 자신의 ID 사본을 가짐

type UnpaidInvoice = {
    InvoiceId : InvoiceId   // id를 "안쪽"에 저장
    // 미납 관련 기타 정보
}

type PaidInvoice = {
    InvoiceId : InvoiceId   // id를 "안쪽"에 저장
    // 완납 관련 기타 정보
}

// 최상위 청구서 타입
type Invoice =
    | Unpaid of UnpaidInvoice
    | Paid of PaidInvoice

• 장점: 패턴 매칭할 때 ID를 포함한 모든 데이터를 한 곳에서 바로 접근 가능

let invoice = Paid {InvoiceId = ...}

match invoice with
| Unpaid unpaidInvoice ->
    printfn "The unpaid invoiceId is %A" unpaidInvoice.InvoiceId
| Paid paidInvoice ->
    printfn "The paid invoiceId is %A" paidInvoice.InvoiceId

TypeScript 대응

// 바깥쪽 접근법
type UnpaidInvoiceInfo = Undefined;
type PaidInvoiceInfo = Undefined;
type InvoiceId = Undefined;

type InvoiceInfo =
  | { kind: "Unpaid"; value: UnpaidInvoiceInfo }
  | { kind: "Paid"; value: PaidInvoiceInfo };

interface InvoiceOutside {
  invoiceId: InvoiceId; // 바깥쪽에 위치
  invoiceInfo: InvoiceInfo;
}

// 안쪽 접근법
interface UnpaidInvoice {
  invoiceId: InvoiceId; // 각 케이스 안쪽에 위치
}
interface PaidInvoice {
  invoiceId: InvoiceId;
}

type Invoice =
  | { kind: "Unpaid"; value: UnpaidInvoice }
  | { kind: "Paid"; value: PaidInvoice };

// 패턴 매칭 (switch)
function describeInvoice(invoice: Invoice): string {
  switch (invoice.kind) {
    case "Unpaid":
      return `미납 invoiceId: ${invoice.value.invoiceId}`;
    case "Paid":
      return `완납 invoiceId: ${invoice.value.invoiceId}`;
  }
}