N° 01 — 목록
'Software Architecture/DDD & Patterns' (3)
-
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..