N° 01 — 목록
'ddd' (5)
-
Software Architecture/DDD & PatternsDDD Patterns - 07. 컨텍스트 통합
두 나라가 교역하는 법 — 바운디드 컨텍스트 통합두 나라가 교역한다고 하자. 한 나라의 언어와 법이 다른 나라에 그대로 통하지 않는다. 공식 대사관(공개 API)을 두거나, 비공식 채널(이벤트 발행)로 소통한다. 국경을 넘을 때 세관(번역 계층)이 물건을 검수하고 규격을 맞춘다. 한 나라가 다른 나라의 법을 그대로 따르면(순응자) 주권을 잃고, 두 나라가 법을 공유하면(공유 커널) 갈등이 잦다.바운디드 컨텍스트 간 통합도 같다. 주문 컨텍스트의 모델이 배송 컨텍스트에 그대로 통하지 않는다 — 두 컨텍스트는 서로 다른 언어(보편 언어)와 규칙을 쓴다. 통합은 두 나라의 외교처럼, 경계에서 번역하고 합의된 방식으로 소통하는 일이다.동기 통합 — 대사관을 통한 공식 접촉가장 단순한 통합은 동기 호출이다. 주문..
-
Software Architecture/DDD & Patterns
DDD Patterns - 05. 빈약한 도메인 모델
겉만 객체인 가구 — 빈약한 도메인 모델가구 전시장에 가면 진짜 가구처럼 보이는 모형이 있다. 형태·색·질감은 같다. 하지만 서랍을 열면 속이 비어 있고, 의자에 앉으면 무너진다. 쓸 수는 없고 볼 수만 있다.빈약한 도메인 모델(anemic domain model)이 이 전시용 가구다. 클래스가 있고, 필드가 있고, getter/setter가 있다. 객체처럼 보인다. 하지만 행동(비즈니스 로직)이 없다 — 서랍이 비어 있다. 비즈니스 규칙은 서비스 계층으로 도망가고, 객체는 데이터를 담는 주머니로 전락한다. Fowler는 이를 "객체지향의 핵심, 즉 데이터와 행동의 결합을 포기한 안티패턴"이라 불렀다.빈약한 모델 vs 풍성한 모델flowchart TB subgraph Anemic["빈약한 도메인 모..
-
Software Architecture/DDD & PatternsDDD Patterns - 03. 애그리거트 설계
계란판 하나가 곧 트랜잭션 하나 — 애그리거트 설계계란판을 옮긴다고 하자. 판 위의 계란들은 함께 옮겨진다 — 하나를 빼면 판이 기울어 다른 계란도 움직인다. 두 판은 따로 옮긴다. 한 판의 계란이 다른 판에 영향을 주지 않는다. 판의 크기가 중요하다 — 너무 크면 무거워서 들기 어렵고(경합), 너무 작으면 관리할 판이 많아진다.애그리거트(aggregate)는 이 계란판에 해당한다. 하나의 트랜잭션에서 함께 변경되는 객체 묶음이고, 다른 애그리거트와는 독립적으로 다뤄진다. 애그리거트 설계는 "어디까지를 한 판에 담을 것인가"를 정하는 일이다. Vernon은 에서 애그리거트를 "일관성 경계(consistency boundary)"라 불렀다 — 한 경계 안은 강한 일관성(한 트랜잭션), 경계 밖은 최종 일관..
-
Software Architecture/DDD & PatternsDDD Patterns - 02. DDD 전술적 설계
신분증 있는 사람과 동전 — 엔터티, 값 객체, 애그리거트사람을 식별할 때 신분증을 본다. 같은 이름, 같은 생김새라도 주민번호가 다르면 다른 사람이다. 반면 동전은 식별 번호가 없다 — 100원짜리 두 개는 교환해도 아무도 모른다. 가치가 같으면 같은 것으로 취급한다. 이 둘은 "객체"처럼 보이지만 식별 방식이 근본적으로 다르다.DDD의 전술적 설계는 도메인을 이루는 객체들을 이렇게 식별 방식과 수명에 따라 나눈다. Evans가 에서 정의한 빌딩 블록이다 — 엔터티, 값 객체, 애그리거트, 도메인 서비스, 도메인 이벤트. 각각 다른 규칙과 책임을 갖는다.엔터티 — 신분증으로 식별되는 객체엔터티(entity)는 식별자(identity)로 구별되는 객체다. 두 Order가 같은 내용(같은 상품, 같은 금액..
-
Software Architecture/DDD & PatternsDDD Patterns - 01. DDD 전략적 설계
한 회사에 "고객"이 다섯 명 있다 — 바운디드 컨텍스트와 보편 언어한 쇼핑몰 회사에서 "고객"이라는 단어를 쓴다고 하자. 영업팀에게 고객은 "계약을 맺을 잠재 대상"이다. 배송팀에게는 "물건을 받는 수령인"이다. CS팀에게는 "문의를 넣는 사람"이다. 재무팀에게는 "매출을 발생시키는 주체"다. 같은 단어인데 뜻이 다르다. 영업팀이 "고객 수가 1만 명 늘었다"고 말하면 배송팀은 "그럼 배송지도 1만 개 추가됐나?"라고 혼란스러워한다.이 혼란의 원인은 언어가 아니라 경계가 없는 것이다. 각 부서가 자기 맥락에서 "고객"을 다르게 쓰는데, 그 맥락의 경계를 명시하지 않으니 같은 단어가 충돌한다. 도메인 주도 설계(DDD)가 푸는 문제가 바로 이것이다.바운디드 컨텍스트 — 언어가 통용되는 국경Eric Eva..