DDD

두 실수를 곱하면 실수가 나온다. 실수를 곱하면 실수가 나온다는 것은 항상 참이므로 실수를 가리켜 곱셍에 대해 닫혀있다 라고 한다.적절한 위치에 반환 타입과 인자 타입이 동일한 연산을 정의하라.구현자가 연산에 사용되는 상태를 포함하고 있다면 연산의 인자로 구현자를 사용

분석 패턴은 업무 모델링 과정에서 발견되는 공통적인 구조를 표현하는 개념의 집합이다. 분석 패턴은 단 하나의 도메인에 대해서만 적절할 수도 있고 여러 도메인에 걸쳐 적용이 가능할 수도 있다.Fowler 1997,p.8운 좋게 적용 가능한 분석 패턴을 알고 있더라도 분석

디자인 패턴이란? 클래스로 코딩되는 연결 리스트와 해시 테이블에 관한 설계를 패턴화한 것이 아니다. 시스템을 지원하는 복잡한 설계에 대한 패턴도 아니다. 특정한 상황에서 일반적인 설계 문제를 해결하고자 상호 교류하는 수정 가능한 객체와 클래스에 관한 설명한 것이다.

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

내부적으로 균열이 발생할 때 이를 빠르게 포착하고 정정할 수 있을 정도로된 컨텍스트 내의 모든 작업을 빈번하게 병합해서 일관성을 유지하는 것을 의미한다. 다수의 사람들이 BOUNDED CONTEXT 내에서 작업할 경우 모델이 단편화될 가능성이 높다.팀규모가 커지면 문제

다른 팀에 속한 사람들은 CONTEXT 간의 경계를 인식하지못한다.자신도 모르는 사이 CONTEXT의 경계를 흐리게 하거나 연결되는 방식을 복잡하게 바꾼다.서로 다른 CONTEXT를 연결해야 하는 경우 CONTEXT는 서로에게 스며드는 경향이 있다.관리자와 팀 구성원

밀접하게 연관된 애플리케이션을 대상으로 작업 중인 팀 간의 협럭이 조율되지 않는다면 잠시 동안은 작업을 진행할 수 있겠지만 각 팀이 만들어낸 결과물을 함께 조립하기는 쉽지 않다.결국 처음부터 CI를 적용했을 때보다 더 많은 시간을 번역 계층을 개발하고 구조를 개선하는데

변경에 대한 거부권이 하류팀에 있거나 변경 요청절차가 지나치게 복잡하다면 상류 팀이 자유롭게 개발을 진행하는 데 하류팀에 속박당할 여지가 있다. 상류 팀은 하류 시스템이 잘못될 것을 염려해서 개발 자체를 억제할지도 모른다.동시에 하류 팀은 상류 팀의 우선순위에 따라

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

개념적인 객체와 행위를 하나의 모델과 프로토콜에서 다른 모델과 프로토콜로 변환하기 위한 메커니즘이다.Bounded Context를 있는 수단이다.다른 시스템과 상호작용하기 위한 거대한 인터페이스를 보유한 새로운 시스템을 구축할 경우 두 모델을 연계하는 데 따르는 어려움

통합에는 언제나 비용이 많이든다.때로는 통합의 혜택이 적은 경우도 있다.BOUNDED CONTEXT가 다른 것과 아무런 관계도 맺지 않도록 선언해서 개발자들이 이 작은 범위 내에서 단순하고 특화된 해결책을 찾을 수 있게 하라.일부 대안은 사전에 차단된다.완벽하게 격리된

혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아내는 과정이다. 팀원들이 시스템의 전체 설계와 해당 설계가 어떻게 함께 조화될지 파악하게끔 돕는다. UBIQUITOUS LANGUAGE의 일부가 될 수 있게 관리 가능한 크기의 핵심 모델을 식별해서 의사소통을

모델의 일부는 전문 지식을 포착하거나 전달하지 않고 복잡성을 더하곤 한다.부수적인 요소는 CORE DOMAIN을 식별하고 이해하는 일을 어렵게 한다.모델은 일반 원칙이나 세부사항 탓에 정체된다.CORE가 모든 상호 관련된 요소와 섞여 있으면 어렵다.현재 진행 중인 프로

프로젝트 초기에는 모델이 존재조차 하지 않지만 모델의 개발에 집중해야 할 필요성은 거기에 있다.개발이 후반부에 이르면 모델을 심층적으로 연구하지 않아도 되는 시스템의 가치를 설명할 필요가 생긴다. 도메인 모델의 핵심적인 측면이 다수의 BOUNDED CONTEXT에 걸쳐

큰 시스템에 해당 시스템의 요소를 전체 설계에 걸친 패턴에서의 역할 측면에서 해석하게 할 수 있는 지배적인 원칙이 없다면 개발자들은 나무만 보고 숲을 보지 못한다.전체의 세부사항을 깊이 파고들지 않고도 전체의 각 부분이 담당하는 역할을 이해할 수 있어야 한다.대규모 구

더 넓은 범위의 규칙으로 제약되기 전까지 모델의 특정 부분을 사용 자의 손에 맡겨야 할 때 생기는 문제를 해결한다.구성가능한 행위를 갖춘 소프트웨어의 요구사항을 다루는데, 여기서 구성 가능하다는 것은 여러 ENTITY 간의 역할과 관계를 초기화 시점이나 실행 시점에서도