DDD

도메인 주도 개발할 때, 애그리거트 정의 다시보기

도메인 주도 개발 시 서비스 다시보기

DDD FACTORY 다시보기

DDD 리파지터리 다시보기

DDD 엔티티 다시보기

DDD VALUE OBJECT 다시보기

프로젝트 설계 참고 사항

DDD 명세 다시 보기

캡슐화 객체가 아름다운 이유는 캡슐화할 수 있기 때문이며, 캡슐화로 클라이언트 코드는 단순해지고 상위 수준의 개념 관점에서 코드를 이해할 수 있다. 캡슐화가 제대로 되지 못한다면, 세부적인 측면을 이해하고자 객체를 깊게 파고들 수 밖에 없다. 캡슐화가 명확하게 이뤄질려면, 해당 도메인의 개념을 반영하도록 클래스와 메서드의 이름일 지어야 한다. 수행 ...

명령과 질의 연산은 크게 명령과 질의라는 두 가지 범주로 나눌 수 있다. 질의는 변수 안에 저장된 데이터에 접근하거나, 저장된 데이터를 기반으로 계산을 수행해서 시스템으로부터 정보를 얻는 연산을 의미한다. 명령은 변수의 값을 변경하는 등의 작업을 통해 시스템의 상

필요성 연산의 부수효과가 단지 구현에 의해서만 함축적으로 정의될 때 다수의 위임을 포함하는 설계는 인과 관계로 혼란스러워진다. 프로그램을 이해하려면 분기 경로를 따라 실행 경로를 추적하는 수밖에 없다. 이렇게 되면 캡슐화의 가치가 사라지고, 구체적인 실행 경로를 추적해야 한다는 필요성으로 추상화가 무의미해진다. 사후조건과 사전조건 사후조건은 연산의...

DDD 독립형 클래스

모델과 디자인 패턴의 연결 Strategy 프로세스에서 변화하는 부분을 분리 프로세스의 규칙과 프로세스를 제어하는 행위를 서로 분리 STRATEGY 디자인 패턴에 따라 규칙이나 대체 가능한 프로세스를 구현 다양한 방식으로 변형된 전략 객체는 프로세스의 서로 다른 처리 방식을 표현 실제 항해 모델 Routing Service가 최적의 경로를 찾을 때...

단일 모델 대규모 시스템의 도메인 모델을 완전하게 단일화한다는 것은 타당하지 않거나 비용 대비 효과적이지 않을 것이다. 한 번에 지나치게 많은 레거시를 교체하려 할지도 모른다. 대규모 프로젝트에서는 능력에 비해 조율에 드는 비용이 너무 커서 난관에 처할지도 모른다

CONTEXT MAP 작성 기준 의사 소통을 위해 컨텍스트 간의 번역에 대한 윤곽을 명확하게 표현하고 컨텍스트 간에 공유해야 하는 정보를 강조함으로써 모델과 모델이 만나는 경계 지점을 서술해야 한다. 각 컨텍스트의 현재 영역을 나타내는 지도를 작성해야 한다. 서로

필요성 밀접하게 연관된 애플리케이션을 대사응로 작업 중인 팀 간의 협력이 조율되지 않는다면 잠시 동안은 작업을 진행할 수 있겠지만 각 팀이 만들어낸 결과물을 함께 조합하기는 쉽지 않을 것이다. 결국 처음부터 CONTINUOUS INTEGRATION을 적용했을 때보다 더 많은 시간을 번역 계층을 개발하고 구조를 개선하는 데 허비하게 될 것이며, 동시에 공...

클라이언트 고유의 도메인 모델 측면에서 기능을 제공할 수 있는 격리 계층을 만들어야 한다.격리 계층은 기존에 이미 존재하는 인터페이스를 거쳐 다른 시스템과 통신하므로 다른 시스템을 거의 수정하지 않아도 된다.해당 계층에서는 내부적으로 필요에 따라 두 모델을 상대로 양방

어떤 하위 시스템을 다른 여러 하위 시스템과 통합해야 할 경우 각 하위 시스템에 대한 번역기를 조정한다면 팀 전체가 교착 상태에 빠질 수 있다.변경이 발생할 때는 유지보수하고 걱정해야 할 일이 더욱 많은 법이다.하위 시스템에 일관성이 있다면 그와 같은 일관성을 다른 하

기존 도메인 모델로 직접 번역하거나 기존 모델에서 직접 번역해 오는 것은 좋은 해결책이 아닐지도 모른다.그러한 모델은 지나치게 복잡하거나 아니면 제대로 도출된 것이 아닐 수도 있으며, 아마 문서화돼 있지 않을 것이다.한 모델을 데이터 교환 언어로 사용한다면 해당 모델은

두 개발 팀이 상류/하류 관계를 맺고 있고 상류 팀이 하류 팀의 필요성을 충족시킬 충분한 동기를 느낄 수 없다면 팀은 속수무책으로 무력해질 수밖에 없다.이타주의를 발판 삼아 상류 개발자들이 약속을 할 수는 있어도 그 약속을 이행할 가능성은 희박하다.상류 팀의 선한 의도

CORE DOMAIN을 찾아 그것을 지원하는 다수의 모델과 코드로부터 쉽게 구별할 수 있는 수단을 제공해야 한다.CORE DOMAIN에 가장 재능 있는 인력을 할당하고 그에 따라 인력을 채용해야 한다.시스템의 비전을 수행하기에 충분한 심층 모델을 찾고 유연한 설계를 개

현재 진행 중인 프로젝트를 위한 것이 아닌 응집력 있는 하위 도메인을 식별해야 한다. 이러한 하위 도메인에서 일반화된 모델 요소를 추출해서 별도 MODULE에 배치할 수 있다.하위 도메인으로 분리되고 나면 해당 하위 도메인의 계속되는 개발에 대해서는 CORE DOMAI