2022. 4. 3. 18:32ㆍ[공부] 독서/DDD (도메인 주도 설계)
http://www.yes24.com/Product/Goods/5312881
요약
Model driven design 에서 모델을 표현하는데 Entity 를 사용한다.
Model driven design 에서 모델을 표현하는데 Value Object 를 사용한다.
Model driven design 에서 모델을 표현하는데 Service 를 사용한다.
Model driven design 에서 모델을 표현하는데 Module 을 사용한다.
Model driven design 에서 모델을 표현하는데 Intention revealiing interface 를 사용한다.
Model driven design 에서 번역을 단순화 하는데 Standalone class 를 사용한다.
Model driven design 에서 변경 비용을 줄이는데 Conceptual contour 를 사용한다.
Model driven design 에서 도메인을 격리하는데 Layerd architecture 를 사용한다.
Value Object 를 캡슐화하는데 Factory 를 사용한다.
Value Object 를 캡슐화하는데 Aggregate 를 사용한다.
Entity 를 캡슐화하는데 Factory 를 사용한다.
Entity 의 무결성을 유지하는데 Aggregate 을 활용한다.
Entity 를 접근하는데 Repository 를 활용한다.
Aggregate 을 캡슐화하는데 Factory 를 사용한다.
Aggregate 를 접근하는데 Repository 활용한다.
Service 에 새로운 이름을 추가하면 Ubquitous language 가 된다.
Value Object 에 새로운 이름을 추가하면 Ubquitous language 가 된다.
Entity 에 새로운 이름을 추가하면 Ubquitous language 가 된다.
Module 에 새로운 이름을 추가하면 Ubquitous language 가 된다.
Ubquitous language 를 소리내어 모델링하면 Model driven design 이된다.
Intention revealiing interface 의 이름의 출처는 Ubquitous language 다.
Intention revealiing interface 를 안전하고 단순하게 하면 Side effect free function 이 된다.
Intention revealiing interface 의 부수효과를 명확히하려면 Assertion을 사용한다.
Assertion 의 컴포지션을 안전하게 만들면 Side effect free function 이 된다.
Model driven design 의 유효성 정의 범위를 결정지으면 Bounded context 가 된다.
Bounded context 에 새로운 이름을 추가하면 Ubquitous language 가 된다.
Bounded context 의 단일화를 유지하는데 Continous intergration 이 사용된다.
Ubquitous language 에서 참조로 모호함을 제거하면 Bounded context 가 된다.
Ubquitous language 를 소리내어 모델링하면 Core domain 이 된다.
Core domain 을 강조하면 Ubquitous language 이 된다.
Core domain 의 방향을 제시하는데 Domain vison statement 가 사용된다.
Core domain 에서 벗어날 대상으로 인식되면 Generic subdomain 이된다.
Core domain 의 재패키지화된 결과는 Segregated core 가 된다.
Core domain 을 구조화하는데 Evolving order 를 활용할 수 있다.
Core domain 의 이질적인 부분을 연결해주는 것을 Context map 이라 부른다.
Generic subdomain 을 디스틸레이션하면 선언적 형식이 된다.
Segregated core 을 디스틸레이션하면 선언적 형식이 된다.
Evolving order 에 구조를 도입하면 Ubquitous language 가 된다.
Evolving order 에 개념을 추가하면 Core domain 이 된다.
Context map 을 구조화하는데 Evolving order 를 활용할 수 있다.
분류
분류 | 개념 |
핵심 | Ubquitous language Model driven design Core domain |
개념 | Entity Value object Service Repository Module |
캡슐화 | Factory Aggregate |
컨텍스트 | Bonded context Context map |
구조화 | Layered architecture Evolving order |
관심사의 분리 | Generic subdomain Segregated core 선언적 형식 디스틸레이션 |
단순화 | Standalone class |
안정화 | 순수 함수 Assertion |
용어 설명
개념 | 설명 |
Aggregate | 데이터 변경을 목적으로 하나의 단위로 다뤄지는 연관 객체의 모음. Aggregate 의 구성 요소중 하나는 루트로 지정되고 외부 참조를 위해 사용됨. |
Analysis pattern | 업무 모델링의 공통적인 구성물을 나타내는 개념의 그룹 |
Assertion | 프로그램의 동작 방식과는 독립적으로 프로그램이 어떤 시점에 지녀야할 상태를 나타내는 문장. 연산의 결과, 구성요소의 불변성을 명시. |
Bounded context | 특정 모델에 포함된 범위가 정해진 적용 가능성. 어떤 것이 일관성을 지녀야하고 독립적으로 개발 가능한지를 분명하게 이해할 때 나오는 개념. |
Cohension | 논리적인 합의와 의존성 |
Command | 시스템에 변화를 초래하는 연산 의도적으로 부수 효과를 만들어내는 연산 |
Conceptual contour | 개념 윤곽. 도메인 자체의 근원적인 일관성. |
Context | 단어나 문장이 해당 의미를 결정한다고 보여지는 환경 |
Context map | Bounded context 간의 실제 관계를 표현하는 것 |
Core domain | 중심적인 열학을 수행하고 애플리케이션을 차별화, 가치있게 만드는 모델 |
Declarative desgin | 특성에 대한 정확한 기술이 실제 소프트웨어를 제어하는데 수단이 되는 프로그래밍의 형태 |
Deep model | 도메인의 초보적 해석을 벗어나 도메인 전문가의 주된 관심사와 가장 깊은 지식을 적확하게 표현한 모델 |
Distillation | 가치있고 유용한 형태로 본질(Core domain)을 추출할 목적으로 구성요소를 분리하는 과정 |
Domain | 지식이나 영향력, 활동의 영역 |
Domain expert | 프로젝트에서 부여된 임무가 소프트웨어 개발이 아니라 애플리케이션 도메인인 구성원 |
Domain layer | Layered architecture 에서 도메인 로직을 책임지는 설계와 구현에 해당하는 부문 |
Entity | 근본적으로 속성이 아니라 연속성과 식별성의 맥락으로 정의되는 객체 |
Factory | 생성 로직을 캡슐화하고 생성된 객체 타입을 추상화하는 메커니즘 |
Function | 부수효과 없이 결과를 계산, 반환하는 연산 |
Immutable | 생성후 식별 가능한 상태가 절대 바뀌지 않는 특성. |
Implicit concept | 모델이나 설계의 의미를 이해하는데 필요하지만 결코 언급되지 않는 개념 |
Intentional reveling interface | 클래스, 메소드, 컴포넌트의 이름이 최초 개발자의 의도를 나타내고, 클라이언트 개발자 의미있는 가치를 전달하는 설계 |
Invariant | 메소드 실행중이나 아직 커밋되지 않은 DB transaction 같이 일시적인 상황을 제외하고 항상 작업을 보장받는 특정 요소에 대한 Assertion |
Large scale structure | 전체 시스템에 대한 설계 패턴을 수립하는 일련의 고수준 개념이나 규칙. 시스템을 넓은 안목에서 논의하고 이해할 수 있게 도와주는 언어 |
Layered architecture | 소프트웨어 시스팀의 관심사, 특히 도메인 계층을 격리해서 관심사를 분리하는 기법 |
Life cycle | 객체가 생성되어 소묠되기 까지 취하는 일련의 상태. 일반적으로 life cycle 은 하나의 상태에서 다른 상태로 변경될 때 무결성을 보장하는 제약조건을 포함함. 시스템과 다른 Bounded context 간의 Entity 이동을 포함할 수 있음 |
Model | 도메인의 선택된 측명을 기술하고 도메인과 관련된 문제를 해결하는데 사용할 수 있는 추상 체계 |
Model driven design | 소프트웨어 요소의 일정 부분이 모델의 요소에 밀접하게 대응되어 있는 설계 |
Modeling paradigm | 도메인에 담긴 개념을 찾아내는 특정 형식. |
Repository | 객체 커랙션을 흉내내어 CRUD 행위를 하는 캡슐화 메커니즘 |
Responsibility | 작업을 수행하고 정보를 알아야할 의무를 표현한 개념 |
Service | 캡슐화된 상태가 없으며 모델에 홀로 존재하는 인터페이스로 제공되는 연산 |
Side effect | 의도적인 갱신 여부나 고의적인 갱신 여부와 관계없이 연산 결과로 발생하는 모든 식별 가능한 상태 변화 |
Side effect free function | = function |
Standalone class | 시스템의 기본 기능과 기본 라이브러리를 제외하고 다른 어떤 것도 참조하지 않은 상태로 이해, 테스트 될 수 있는 클래스 |
Stateless | 어떤 컴포넌트의 history 와 관계없이 모든 연산을 사용할 수 있는 설계 요소의 특성. Stateless 컴포넌트는 전역적으로 접근이 가능하고, 변경도 가능하지만 컴포넌트의 행위에 영향을 주는 private state 를 유지하지는 않음. |
Strategic design | 시스템의 큰 부분에 적용되는 모델링과 설계 결정. |
Supple design | Deep model 에 내재된 가치를 클라이언트 개발자에게 예상되는 결과로 명확하고, 효과적이며 유연한 표현이 가능하도록 만드는 설계 방식. |
Ubiquitous language | 도메인 모델에 따라 구조화 되어 모든 팀원이 소프트웨어와 팀 활동을 하는데 사용하는 언어 |
Unification | 언어가 모호하지 않고 어떠한 규칙도 모순되지 않는 모델의 일관성 |
Value Object | 일부 특징과 속성을 기술하지만 식별 가능하지 못하는 객체 |
Whole value | 다하나의 완전한 개념을 모델화한 객체 |
'[공부] 독서 > DDD (도메인 주도 설계)' 카테고리의 다른 글
도메인 주도 설계 (3/3) 심화 (0) | 2022.04.04 |
---|---|
도메인 주도 설계 (2/3) 기본 (0) | 2022.04.03 |