- 문서 


    문서는 프로젝트 활동과 관련을 맺고 있어야 한다.

 

    Ubiquitous languzge언어로 작성하라

 

    문서를 최소한으로 유지하고 대화를 보완하는 데 집중하라

 

    문서는 유요한 상태를 유지하고 최신 내용을 담고 있어야 한다.

 

- 하나의 모델이 구현, 설계, 의사소통의 기초가 되야 한다

 

- 설명을 위한 모델!!

 

- 모델과 설계를 연계한는 것이 실용적이다.

 

- 소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게 하라. 또한 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있게 수정하라

 

- 유비쿼터스 언어를 지원하는 것과 더불어 분석과 설계의 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만들어내야 한다.

 

- DDD에서는 모든 단일 컨텍스트 내에서 오로지 하나의 모델을 다룰 것을 요구한다.

 

- 코드의 변경이 곧 모델의 변경이다. 

 

- 도메인의 격리

    시스템에서 도메인과 관련이 적은 기능으로부터 도메인 객체를 분리할 필요가 있다. 이러한 기법을 Layered architecture(계층형 아키텍처) 이라고 한다.

 

    매우 복잡한 작업을 처리하는 소프트웨어를 만들 경우 관심사의 분리가 필요하며, 이로써 격리된 상태에 있는 각 설계 요소에 집중할 수 있다. 동시에 시스템 내의 정교한 상호작용은 

    그러한 분리와는 상관없이 유지돼야 한다.

 

    계층화의 핵심 원칙은 한 계층의 모든 요소는 오직 같은 계층에 존재하는 다른 요소나 계층상 '아래'에 위치한 요소에만 의존한다는것이다 위로 거슬러 올라가는 의사소통은 반드시 간적접인 메커니즘을 

    거처야 한다.

 

    4가지 계층으로 이루어짐                                                                                                                  

    사용자 인터페이스 : 사용자에게 정보를 보여주고 사용자의 명령을 해석하는 일을 책임진다.

    응용계층 : 소프트웨어가 수행할 작업을 저으이하고 표현력 있는 도메인 객체가 문제를 해결하게 한다. 이 계층에서 책임지는 작업은 업무상 중요하거나 다른 시스템의 응용 계층과 상호작용하는데 필요한 것들이다.

    도메인 계층 : 업무 개념과 업무 상황에 관한 정보, 업무 규칙을 표현하는 일을 책임진다.

    인프라스트럭쳐 계층 상위 계층을 지원하는 일반화된 기술적 기능을 제공한다. 메시지 전송, 도메인 영속화, UI위젯을 그리는 것등 

 

    - 복잡한 프로그램을 여러 개의 계층으로 나누어라

    - 상위 계층과의 결합을 느슨하게 유지하라.

    - 도메인 객체는 도메인 모델을 표현하는 것에만 집중 할 수 있다.

    

- 계층 간 관계 설정

    각 계층은 설계 의존성을 오직 한 방향으로만 둬서 느슨하게 결합된다. 

    하위 수준의 객체가 상위 수준의 객체와 소통해야 할 경우 콜백이나 ovserver패턴처럼 계층 간에 관계를 맺어주는 아키텍처 패턴을 활욜 할 수 있다.

 

-smart ui 안티패턴

    모든 업무 로직을 사용자 인터페이스에 넣어라. 애플리케이션을 작은 기능으로 잘게 나누고, 나눈 기능을 각기 분리된 사용자 인터페이스로 구현해서 업무 규칙을 분리된 사용자 인터페이스에 들어가게 하라.

 

    단점 

        데이터 베이스를 이용하는 방식 말고는 여러 애플리케이션을 통합하기가 수월하지 않다.

        행위를 재사용하지 않으며 업무 문제에 대한 추상화가 이뤄지지 않는다. 업무 규칙이 적용 되는 연만사다 업무 규칙이 중복된다.

        신속한 프로토타입 작성과 반복주기가 smart ui가 지닌 태생적인 한계에 도달하게 된다. 이는 추상화의 부재로 리팩터링의 여지가 제한되기 때문이다.

        복잡성에 금방 압도되어 애플리케이션의 성장 경로가 순전히 부가적인 단순 응용으로만 향한다 우아한 방법으로 더욱 풍부한 행위를 갖출 수 있는 방법은 없다.

 

-연관관계를 줄여라(다루는 방법)

    1. 탐색 방향을 부여한다.

    2. 한정자를 추가해서 사실상 다중성을 줄인다.

    3. 중요하지 않은 연관관계를 제거한다.

 

- ENTITY

    - 자신의 생명주기 동안 형태와 내용이 급격하게 바뀔 수도 있지만 연속성은 유지해야한다.

    - 식별성이 저의돼 있어야 한다.

    - 사람,도시,자동차,복권티켓,은행거래 등

 

    ex) 경기장의 좌석을 예약하는 애플리케이션에서는 좌석과 참석자를 ENTITY로 다룰 수 있다 지정석인 경우 고유의 좌석번호가 적혀 있을 것이므로 좌석은 유일한 식별자를 갖는다.

        하지만, 입장권을 가진 사람이 빈 좌석을 찾아 아무 데나 앉을 수 있는 "일반석"이라면 개별좌석을 구분하지 않아도 된다. 이 경우 Entity가 아니며 식별자는 필요하지 않다.

 

    - 가장 기본적인 책임은 객체의 행위가 명확하고 예측 가능해질 수 있게 연속성을 확립하는 것이다.

 

- Value Object

    - ENTITY의 식별성을 관리하는 일은 매우 중요하지만 그 밖의 객체에 식별성을 추가한다면 시스템의 성능이 저하되고, 분석 작업이 별도로 필요하며, 모든 객체를 동일한 것으로 보이게 해서 모델이 혼란스러워질 수 있다.

    - 소프트웨어 설계는 복잡성과 끊임없는 전투다. 그러므로 우리는 특별하게 다뤄야 할 부분과 그렇지 않은 부분을 구분해야 한다.

    - 식별성이 없는 것으로만 생각한다면, 추가할 게 그리 많지 않다.

    - 즉, 사물을 서술하는 객체다.

    - 종종 한 연산에서 사용할 목적으로 만들어진 후 폐기되는 것처럼 일시적인 용도로 사용되기도 한다.

 

    모델에 포함된 어떤 요소의 속성에만 관심이 있다면 그것을 VALUE OBJECT로 분류하라.

    VALUE OBJECT는 불변적으로 다뤄라!

 

    ex) 한 객체가 다른 여러 객체에서 참조되고 있다면 그러한 객체 가운데 일부는 가까이에 위치하지 않을 것이므로 데이터를 가져오는 데 물리적인 연산이 추가적으로 필요할 것이다. (동일한 데이터에 여러 개의 사본을 저장하는 기법

    을 역정규화라고하며 접근 시간이 더 중요한 경우에 사용한다.)

 

- MODULE(모듈, 패키지라고 함)

    보통 module을 토대로 모델을 두 가지 측면에서 바라 볼 수 있다, 즉 사람들은 전체에 압도되지 않고도 세부사항을 보거나, 세부 사항을 배제한 상태에서 module 간의 관계를 볼 수 있다.

    모듈간의 결합도는 낮아야 하고 모듈간의 응집도는 높아야한다.(모듈로 쪼개지는 것은 코드가 아닌 개념이다)

    

    모듈은 모델과 함께 발전해야 한다. 

 

- Aggregate

    우리가 데이터 변경의 단위로 다루는 연관 객체의 묶음을 말한다. Aggregate에는 루트와 경계가 있다.

    경계는 Aggregate에 무엇이 포함되고 포함되지 않는지를 정의한다. 루트는 단 하나만 존재하며, Aggregate에 포함된 특정 ENTITY를 가리킨다.

    경계 안의 객체는 서로 참조 할 수 있지만, 경계 바깥의 객체는 해당 Aggregate의 구성요소 가운데 루트만 참조할 수 있다.

    루트 이외의 ENTITY는 지역 식별성을 지니며, 지역 식별성은 Aggregate 내에서만 구분되면 된다. 이는 해당 Aggregatedml 경계 밖에 위치한 객체는 루트 ENTITY의 컨텍스트 말고는 Aggregate의 내부를 볼 수 없기 때문이다.

 

    ENTITY와 VALUE OBJECT를 Aggregate로 모으고 각각에 대해 경계를 정의하라.

    한 ENTITY를 골라 Aggregate의 루트로 만들고 Aggregate 경계 내부의 객체에 데해서는 루트를 거쳐 접근할 수 있게 하라. Aggregate 밖의 객체는 루트만 참조할 수 있게 하라.

    내부 구성요소에 대한 일시적인 참조는 단일 연산에서만 사용할 목적에 한해 외부로 전달될 수 있다. 루트를 경유하지 않고는 Aggregate의 내부를 변경할 수 없다. 이런식으로 Aggregate의 각 요소를 배치하면 Aggregate 안의 객체와

    전체로서의  Aggregate의 상태를 변경할때 모든 불변식을 효과적으로 이행할 수 있다.

 

-FACTORY

    어떤 객체나 전체 Aggregate를 생성하는 일이 복잡해지거나 내부 구조를 너무 많이 드러내는 경우 FACTORY가 캡슐화를 제공해준다.

 

    복잡한 객체와 Aggregated의 인스턴스를 생성하는 책임을 별도의 객체로 옮겨라.

 

    FACTORY를 잘 설계학 위한 두가지 기본 요건

        1. 각 생성 방법은 원자적이어야 한다, 생성된 객체나 Aggregate의 불변식을 모두 지켜야 한다.

        2. 생성된 클래스보다는 생성하고자 하는 타입으로 추상화돼야 한다.

 

- 생성자만으로 충분한 경우

    클래스가 타입인 경우, 인터페이스를 구현하는 식으로 다형적으로 사용되지 않는 경우

    클라이언트가 strategy를 선택하는 한 방법으로서 구현체에 관심이 있는 경우

    클라이언트가 객체의 속성을 모두 이용할 수 있어서 클라이언트에게 노출된 생성자 내에서 객체 생성이 중첩되지 않는 경우

    생성자가 복잡하지 않은 경우

    공개 생성자가 FACTORY와 동일한 규칙을 반드시 준수해야 하는 경우, 이때 해당 규칙은 생성된 객체의 모든 불변식을 충족하는 원자적인 연산이어야 한다.

 

- 인터페이스 설계

    각 연산은 원자적이어야한다.

    FACTORY는 자신에게 전달된 인자와 결합될 것이다. 입력 매개변수를 신경 써야한다. 아니면 의존성의 덫이 만들어질 수 있다.

 

 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

- 명확한 모델을 발견하는 것이다.

 

- 다소 불명확한 개념을 모델링 하는 법

    - 명시적인 제약조건

        흔히 제약조건은 암시적인 상태로 존재하며, 이를 명시적으로 표현하면 서계를 대폭 개선할 수 있다.

        (간단한 불변식의 경우에는 내용물을 변경하는 개별 연산 안에 조건 로직을 사용해서 불변식을 보장할 수 있다,)

        제약조건을 자체적인 메서드로 분리하면 제약조건에 이름을 부여해서 제약조건을 멱확하게 표현할 수 있다.

    - 도메인 객체로서의 프로세스

        알고리즘 자체 또는 그것의 일부를 하나의 객체로 만드는 것이다.

 

-specification 

    다른 객체에 대한 제약조건을 기술하며, 제약조건은 존재할 수도 존재하지 않을 수도 있따.(또, 명시된 기준을 만족하는지 검사할 수 있다)

 

    매우 상이해 보이는 애플리케이션 기능을 하나로 통합해 준다.

    

    1. 객체가 어떤 요건을 충족시키거나 특정 목적으로 사용할 수 있는지 가늠하고자 객체를 검증

    2. 컬렉션 내의 객체를 선택

    3. 특정한 요구사항을 만족하는 새로운 객체의 생성을 명시

 

    1.검증  

    2.선택(또는 질의)   

    3.요청 구축 생성 (specification을 사용해서 생성기의 인터페이스를 정의하면 생성할 결과물을 명시적으로 인터페이스에 포함시킬 수 있따.)

        - 생성기의 구현을 인터페스로부터 분리할 수 있따. specification은 생성할 결과물에 대한 요구사항은 선언하지만 결과물을 생성하는 방법은 정의하지 않는다.

        - specification을 사용한 인터페이스는 생성 규칙을 명시적으로 전해주므로 개발자들이 연산의 세부적인 사항을 이해하지 않고도 생성기의 결과물을 예상할수있따.

        - 생성기는 단순히 specification에 포함된 조건에 따라 객체를 생성하는 반면 생성 요청을 표현하는 코드는 클아이언트에 존재하므로 더 유연한 인터페이스를 얻거나 더 유연하게 개선할 수 있따.

 

유연한 설계를 만들 수 있는 패턴 집합

    -intention-revealing interface(의도를 드러내는 인터페이스)

        도메인 개념을 반영하도록 클래스와 메서드의 이름을 지어야 한다.

        결과와 목적만을 표현하도록 클래스와 연산의 이름을 부여하라

    -side-effect-free function(부수효과가 없는 함수)

        명령과 질의를 엄격하게 분리된 서로 다른 연산으로 유지하는 것이다.

        명령과 질의를 분리하는 대신 value Object를 생성해서 반환한다.

    -assertion

        assertion을 사용하면 명령 entity 부수효과가 명확해지고 다루기 쉬워진다.

    -conceptual contour(개념적 윤곽)

        도메인을 중요 영역을 나누는 것과 관련한 직관을 감안해서 설계요소를 응집력있는 단위로 분해해라. 계속적인 리팩터링을 토대로 변경되는 부분과 변경되지 않는 부분을 나누는 중심 축을 식별하고,

        변경을 분리하기 위한 패턴을 명확하게 표현하는 conceptual contour

    -standalone class(독립형 클래스)

        의존성을 낮춰야 함

        낮은 결합도는 객체 설계의 기본 원리다. 가능한 한 늘 결합도를 낮추고자 노력하라. 현재 싱황과 무관한 모든 개념을 제거하라. 그러면 클래스가 완전히 독립적으로 바뀌고 단독으로 컴토하고 이해할 수 있을 것이다.

    -closure of operation(연산의 닫힘)

        적절한 위치에 반환 타입과 인자 타입이 동일한 연산을 정의하라 구현자가 연산에 사용되는 상태를 포함하고 있다면 연산의 인자로 구현자를 사용하는 것이 효과적이므로 인자의 타입과 반환 타입을 구현자의 타입과 동일하게 정의한다.

        주로 VALUE OBJECT의 연산을 정의하는 데 주로 사용된다.

 

분석 패턴

    -strategy 객체 (분기를 둬서 어떤 policy를 전달하느냐를 결정)

    -composite 내부에 포함된 모든 구성요소를 포괄한느 추상타입을 정의해서 사용하는 것

    -flyweight value object집합이 자주사용 되는 경우 적합

 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

bounded context 

 

context map

 

sharedd kernel(공유 커널)

    밀접하게 연관된 애플리케이션을 대상으로 작업중인 팀 간의 협력이 조율되지 않는다면 잠시 동안은 작업을 진행할 수 있겠지만 각 팀이 만들어낸 결과물을 함께 조합하기는 쉬빚 않을것이다.

    - 두 팀 간에 공유하기로 한 도메인 모델의 부분집합을 명시하라. 여기에는 모데르이 부분집합 뿐만 아니라 모델 요소와 연관된 코드나 데이터베이스 설계의 부분집합까지도 포함된다.

    - 명시적으로 공유하는 부분들은 특별한 상태를 가지며, 다른 팀과의 협의 없이는 변경할 수 없다.

    - 기능 시스템을 자주 통합하라. 하지만 개별 팀에서 수행하는 CI빈도보다는 더 적은 빈도로 통합하라. 통합할 때는 양 팀에서 작성한 테스트를 모두 실행하라.

 

customer/supplier/ development team(고객/공급자 개발 팀)

    한 하위 시스템이 다른 시스템에 본질적으로 데이터를 공급할 때가 있다. 하류 컴포넌트는 상류 컴포넌트에 피드백을 거의 제공하지 않는 분석 작업이나 여타 다른 기능을 수행하며, 모든 의존선을 단방향으로 흐른다.

    상류 하위 시스템과 하위 시스템은 자연스럽게 두개의 bounded context로 나뉜다.

 

    두 팀 간에 명확한 고객/공급자 관계를 확립하라. 계획 회의에서 하류 팀이 상류 팀에 대한 고객 역할을 맡게 하라. 하류 요구사항에 대한 작업을 협상하고 이에 대한 예산을 책정해서 모든 이들이 일정과 약속을 이해할 수 있게 하라.

    결과로 예상되는 인터페이스를 검증하게 될 자동화된 인수 테스트를 함께 개발하라 이 테스트를 상류 팀의 테스트 스위트에 추가해서 지속적인 통합의 일부로 실행되게 하라.

 

conformist 

    sharedd kernel 밀접하게 조율하는 두 팀 간의 협력관계를 다룬다면, conformist는 협력에 관심이 없는 팀과의 통합문제를 다룬다. 독립적인 모델을 포기하는 것

 

ANTICORRUPTION LAYER (오류방지계층)

    클라이언트 고유의 도메인 모델 측면에서 기능을 제공할 수 있는 격리 계층을 만들어라. 격치 계층은 기존에 이미 존재하는 인터페이스를 거쳐 다른 시스템과 통신하므로 다른 시스템을 거의 수정하지 않아도 된다.

    해당 계층에서는 내부적으로 필요에 따라 두모델을 상대로 양방향으로 번역을 수행한다.

 

    보통 service의 집합(간혹 entitiy) 으로 표현된다. 연결 계층

 

separate ways (각자의 길)

    우리는 철저하게 요구사항들을 조사해야 한다. 두 기능 간의 관계가 필수적인 것이 아니라면 두 기능은 서로 관계를 끊을 수도 있다.

 

OPEN HOST SERVICE(공개 호스트 서비스)

    하위 시스템을 필요로 하는 곳이 많다면 좀더 유연한 접근법이 필요하다. 어떤 하위 시스템을 다른 여러  하위 시스템과 통합해야 할 경우 각 하위 시스템에 대한 번역기를 조정한다면 팀 전체가 교착 상태에 빠질수 있다.

    하위 시스템 접근과 관련된 프로토콜을 일련의 service로 정의하라. 프로토콜을 공개해서 개발 중인 시스템과 통합하고자 하는 모든 이들의 해당 프로토콜을 사용할 수 있게 하라. 새로운 통합 요구사항을 처리하게끔 프로토콜을 개선하고

    확장하되 특정한 한 팀에서 요청해 오는 독특한 요구사항은 제외하라. 그와 같은 특수한 경우에는 일회성 번역기로 프로토콜을 보강해서 공유 프로토콜을 단순하고 일관되게 유지하라.

 

PUBLISHED LANGUAGE(공표된 언어)

    두 bounded context의 모델 간에 이뤄지는 번역에는 공통의 언어가 필요하다.

    필요한 도메인 정보를 표현할 수 있는 적절히 문서화된 공유 언어를 공통의 의사소통 매개체로 사용해서 필요에 따라 해당 언어로, 또는 해당 언어로부터 번역을 수행하라

 

경계의 변형

    규모가 큰 bounded context가 선호되는 경우

        사용자의 작업 흐름이 단일화된 모델을 토대로 처리될 때 더 매끄럽게 진행된다.

        개별적인 두 모델의 매핑을 더하는 것보다 일관성 있는 하나의 모델을 이해하기가 더 쉽다.

        두 모델 간의 번역이 어려울 수 있따.

        공유 언어를 토대로 팀의 의사소통이 명확해진다.

    규모가 작은 bounded context가 선호되는 경우

        개발자 간의 의사소통에 따른 과부하가 줄어든다.

        소규모 팀과 고드 기반을 토대로 ci가 쉬워진다.

        대형 컨텍스트에는 용도가 다양한 추상화 모델을 요구할 수도 있는데, 이 경우 제공하기 힘든 기술이 필요할 때가 있따.

        각기 다른 모델은 특수한 요구사항을 해결하는 데 도움이 된다.

 

디스틸레이션

    규모가 큰 시스템에서는 격리된 도메인조차도 관리할 수 없을 정도로 복잡해질지도 모른다.

    디스틸레이션은 혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아내는 과정이다.

    CORE DOMAIN의 추출!!

 

GENERIC SUBDOMAIN(일반 하위 도메인)

    모델의 일부는 전문 지식을 포착하거나 전달하지 않고 복잡성을 더하곤 한다. 부수적인 요소는 core domain을 식별하고 이해하는 일을 더욱 어렵게 만든다.

 

    현재 진행 중인 프로젝트를 위한 것이 아닌 응집력 있느 하위 도메인을 식별하라. 이러한 하위 도메인에서 일반화된 모델 요소를 추출해서 별도 module에 배치하라 

    일단 하위 도메인이 분리되고 나면 해당 하위 도메인의 계속 되는 개발에 대해서는 core domain보다 낮은 우선순위를 부여하고 그 일에 핵심 개발자를 배치하지 않는다.

 

DOMAIN VISION STATEMENT(도메인 비전 선언문)

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

    많은 프로젝트 팀에서는 관리를 위해 '비전 선언서'를 작성한다.

 

    약 한 페이지 분량으로 CORE DOMAIN을 짧게 기술하고 그것이 가져올 가치에 해당하는 가치제안을 작성하라!

 

디스틸레이션 문서

    Core domain 과 core의 구성요소 사이에서 일어나는 상호작용을 기술하는 매우 간결한 문서

    core domain의 본질적인 면면의 윤곽을 드러낸다면 디스틸레이션 문서는 모델 변경의 중요성을 나타내는 실질적인 지표로 작용한다. 모델이나 코드 변경이 디스틸레이션 문서에 영향을 주면 다른 팀원과의

    사으이가 필요하다. 

 

cohesive mechanism(응집렬 있는 메커니즘)

    개념적으로 cohesive mechanism을 별도의 경량 프레임워크로 분할하라 이제 도메인의 다른 요소들은 해법의 복잡성을 프레임워크에 위임해서 문제를 표현하는 데 집중할 수 있따.

    알고리즘을 빼서 프레임워크화 하라!

 

    메커니즘이 도메인 모델에 통합돼 있었다면 두 가지 점에서 비용이 발생했을 것이다. 모델은 추후 선택사항에 제한을 두면서 특정한 문제 해결 방법과 결합됐을 것이다.

 

segregated core(분리된 핵심)

    1. core 하위 도메인을 식별한다.

    2. 새로운 module관련 클래스를 옮긴다. 이때 module의 이름은 관련 개념에 따라 짓는다.

    3. 개념을 직접적으로 표현하지 않는 서버 데이터와 기능으로 코드를 리팩터링한다. core 하위 도메인의 불순물을 제거하고 그곳에서 다른 패키지를 참조하는 바를 명시적이로 그 자체로도 이해할 수 있는 상태로 만든다.

    4. 새로생긴 module의 관계와 상호작용을 더욱 단순하고 전달력 있게 만든다.

 

abstract core(추상화된 핵심)

    별도 module의 하위 도메인 간에 상호작용이 활발한 경우 module 간에 참조가 많이 만들어져야 해서 분할의 가치가 상당수 사라지거나, 또는 상호작용이 간접적으로 일어나야 해서모델이 불분명해진다.

 

    모델의 가장 근본적인 개념을 식별해서 그것을 별도의 클래스나 추상 클래스, 또는 별도 인터페이스로 수정하라 이 추상 모델이 중요 컴포넌트 간에 발생하는 상호작용을 대부분 표현할 수 있게끔 설계하라.


대규모 구조
    책임 계층 을 나누어라
    각 객별 객체에 손수 만든 책임이 할달돼 있다면 가이드라인드 없고, 균일함도 없고, 넓은 범위에 걸친 도메인을 동시에 다룰 능력도 없는 셈이다.
    큰 모델에 응집력을 부여하려면 그러한 책임할당에 특정 구조를 도입하는 것이 도움이 된다.
    ex) 의사결정지원, 정책,운영,잠재기능 등


평가
    1. context map을 그려라 일관된 context map 을 그릴 수 있는가? 그렇지 않다면 모호한 상황이 있는가?
    2. 프로젝트상의 언어를 쓰는 데 힘써라. 유비쿼터스 언어가 있는거 유비쿼터서은어가 개발에 도움을 줄 만큼 풍부한가?
    3. 무성이 중요한지 이해하라 core domain을 식별했는가? domain vision statement가 있는가? domain vision statement를 작성할수있는가?
    4. 프로젝트 사용하는 기술이 DDD에 유리한가 불리한가
    

+ Recent posts