Ddd

정의 Domain-Driven Design(DDD)은 도메인의 프로세스와 규칙을 풍부하게 담은 도메인 모델을 프로그래밍하는 데 개발의 중심을 두는 소프트웨어 개발 접근법이다. 2003년 Eric Evans의 책 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 이름이 유래했다. Evans 본인은 DDD를 세 가지로 요약한다. Core Domain에 집중한다. 도메인 전문가와 소프트웨어 전문가의 창의적 협업으로 모델을 탐구한다. 명시적으로 경계 지어진 컨텍스트 안에서 하나의 보편 언어를 사용한다. Martin Fowler는 Evans의 기여를 “모델링 표기법 논쟁을 넘어서는 어휘를 만든 것"으로 평가한다. 도메인 모델이 중요하다는 주장 자체는 1980~90년대 데이터 모델링과 객체지향 분석에서도 있었지만, Evans는 그 접근을 이야기할 수 있는 용어 체계(Entity, Value Object, Aggregate, Bounded Context 등)를 정리했다. ...

정의 Bounded Context는 특정 모델이 정의되고 적용되는 경계에 대한 기술이다. 보통 하나의 하위 시스템이거나 특정 팀의 작업 범위에 대응한다. Fowler는 이를 “DDD 전략적 설계의 중심 패턴"이라고 부른다. DDD가 큰 모델을 다루는 방식은 그것을 여러 Bounded Context로 나누고, 그 사이의 관계를 명시적으로 밝히는 것이다. 동작 원리 큰 프로젝트에는 항상 여러 모델이 존재한다 Evans가 제시하는 근거는 세 가지다. 두 하위 시스템이 서로 다른 사용자 집단을 대상으로 하고, 하는 일이 달라서 서로 다른 모델이 유용한 경우가 흔하다 독립적으로 일하는 팀들은 소통 부족으로 같은 문제를 다른 방식으로 해결한다 도구 자체가 달라서 코드를 공유할 수 없는 경우도 있다 여러 모델이 존재하는 것은 불가피하다. 문제는 서로 다른 모델에 기반한 코드가 합쳐질 때 생긴다. 소프트웨어에 버그가 생기고, 신뢰할 수 없게 되고, 이해하기 어려워진다. 팀원 간 소통도 혼란스러워진다. 어떤 컨텍스트에서 모델을 적용하면 안 되는지가 불분명해지기 때문이다. ...

정의 Ubiquitous Language(보편 언어)는 도메인 모델을 중심으로 구조화되어, 하나의 Bounded Context 안에서 팀 전원이 사용하는 언어다. 팀의 모든 활동을 소프트웨어와 연결하는 역할을 한다. Evans가 이 용어로 가리키는 것은 개발자와 사용자 사이에 공통되고 엄격한 언어를 구축하는 실천이다. 이 언어는 소프트웨어에서 사용하는 도메인 모델에 기반해야 한다. 소프트웨어는 모호함을 잘 처리하지 못하므로 언어가 엄격해야 하기 때문이다. 동작 원리 언어가 파편화되는 방식 하나의 Bounded Context 안에서도 언어는 여러 갈래로 쪼개진다. 모델이 기술 담당자를 위한 UML 다이어그램을 그리는 데만 쓰인다면, DDD의 핵심인 창의적 협업에 기여하지 못한다 도메인 전문가는 자기 업계 용어를 쓰고, 기술 담당자는 설계 관점에서 도메인을 논하기 위한 자기 언어를 쓴다 일상 대화의 용어가 코드에 박힌 용어와 단절된다. 코드야말로 소프트웨어 프로젝트의 가장 중요한 산출물인데도 그렇다 같은 사람도 말할 때와 쓸 때 다른 언어를 쓴다. 그래서 도메인을 가장 예리하게 표현한 말이 순간적인 형태로 등장했다가 코드에도 문서에도 남지 않고 사라진다 번역은 소통을 무디게 만들고 지식 정제를 빈혈 상태로 만든다. 그리고 이 방언들 중 어느 것도 공통 언어가 될 수 없다. 어느 것도 모든 요구를 충족시키지 못하기 때문이다. ...

개요 Bounded Context를 정의하는 것만으로는 부족하다. 전체를 보는 시야가 없으면 다음 문제가 남는다. 다른 모델의 컨텍스트가 여전히 모호하고 계속 변한다 다른 팀 사람들은 컨텍스트 경계를 잘 모르므로, 모르는 채로 경계를 흐리거나 연결을 복잡하게 만드는 변경을 한다 경계가 분명해도, 다른 컨텍스트와의 관계가 모델의 성격이나 변경 속도에 제약을 건다. 이 제약은 주로 비기술적 경로로 나타나기 때문에 그것이 영향을 주는 설계 결정과 연결짓기 어렵다 Context Map은 이 관계들을 명시적으로 그리는 작업이다. 그리는 방법 Evans의 처방은 다음과 같다. ...

정의 Aggregate는 하나의 단위로 취급할 수 있는 도메인 객체의 묶음이다. 주문과 주문 항목이 전형적인 예다. 이들은 별개의 객체지만 주문(과 그 항목들)을 하나의 Aggregate로 다루는 것이 유용하다. Fowler가 정리한 핵심 속성은 셋이다. Aggregate의 구성 객체 중 하나가 Aggregate Root가 된다. 외부에서 오는 참조는 Root만 향해야 하며, 그래야 Root가 Aggregate 전체의 정합성을 보장할 수 있다 Aggregate는 데이터 저장의 기본 전송 단위다. 로드와 저장은 Aggregate 전체 단위로 요청한다 트랜잭션은 Aggregate 경계를 넘지 않아야 한다 DDD의 Aggregate는 리스트나 맵 같은 컬렉션 클래스와 혼동되곤 한다. 컬렉션은 범용 구조이고, DDD Aggregate는 주문·진료 방문·재생목록 같은 도메인 개념이다. 하나의 Aggregate가 여러 컬렉션과 단순 필드를 함께 가지는 경우가 많다. UML 등 다른 맥락에서 쓰이는 “aggregate"는 DDD Aggregate와 같은 개념이 아니다. ...

개요 Evans는 모델 요소를 Entity, Value Object, Service로 분류했다. Fowler는 이를 Evans Classification이라고 부르며, 프로그래밍 언어와 다이어그램 표기법 어느 쪽도 채우지 못했던 사고의 공백을 메웠다고 평가한다. Entity와 Value Object를 가르는 기준은 동일성(identity) 이다. 필드가 몇 개인지, 얼마나 복잡한지는 기준이 아니다. Entity 정의 많은 객체가 속성이 변하더라도 생애주기를 관통하는 연속성과 동일성을 나타낸다. 어떤 객체는 주로 속성으로 정의되지 않는다. 이들은 시간을 관통하고 종종 서로 다른 표현을 가로지르는 동일성의 실을 나타낸다. Evans의 문제 서술은 다음과 같다. ...

Repository 정의 Repository는 보편 언어로 표현된 Aggregate에 대한 조회 접근이다. Evans가 이 패턴을 도입한 문제는 두 가지다. 첫째, 단지 무언가를 찾기 위한 탐색 가능한 연관관계가 늘어나면 모델이 흐려진다. 성숙한 모델에서 쿼리는 종종 도메인 개념을 표현한다. 둘째, 그러나 쿼리 자체가 문제를 일으킨다. 대부분의 DB 접근 인프라를 적용하는 순전한 기술적 복잡도가 클라이언트 코드를 빠르게 압도하고, 그것이 개발자로 하여금 도메인 계층을 멍청하게 만들도록 이끌어 모델을 무의미하게 만든다. 제약 없는 쿼리는 객체에서 특정 필드만 빼내 캡슐화를 위반하거나, Aggregate 내부에서 몇 개의 특정 객체만 인스턴스화하여 Aggregate Root를 무방비 상태로 만들고 이 객체들이 도메인 모델의 규칙을 강제하는 것을 불가능하게 만든다. 도메인 로직이 쿼리와 애플리케이션 계층 코드로 옮겨가고, Entity와 Value Object는 단순한 데이터 컨테이너가 된다. ...

정의 Anemic Domain Model(빈혈 도메인 모델)은 도메인 객체에 getter와 setter만 있고 행위는 거의 없으며, 모든 도메인 로직이 Service 객체에 있는 설계다. Martin Fowler가 2003년에 안티패턴으로 지목했고, Eric Evans도 같은 진단에 동의했다. Fowler는 이것을 “꽤 오래 존재해 온 안티패턴"이라고 부르면서, 제대로 된 Domain Model의 지지자로서 이것이 유행하는 것은 좋은 일이 아니라고 못 박는다. 증상 Fowler의 서술이 정확하다. 빈혈 도메인 모델의 기본 증상은 처음 보면 진짜처럼 보인다는 것이다. 도메인 공간의 명사를 따라 이름 붙은 객체들이 있고, 이 객체들은 진짜 도메인 모델이 가진 풍부한 관계와 구조로 연결되어 있다. ...