일련의 일관성 규칙이 Aggregate의 경계 내에 적용됨 |
| Analysis Pattern
(분석 패턴) | - 업무 모델링의 공통적인 구성물을 나타내는 개념의 그룹
오직 하나의 도메인과 관련돼 있거나 여러 도메인에 걸쳐 있을 수 있음 |
| Assertion
(단언) | - 프로그램의 동작방식과는 독립적으로 프로그램이 어느 시점에 지녀야 할 정확한 상태를 나타내는 문장
일반적으로 Assertion은 연산의 결과나 설계 구성요소의 불변식을 명시 |
| Bounded Context
(제한된 컨텍스트) | - 특정 모델에 포함된 범위가 정해진 적용 가능성
컨텍스트를 제한하면(Bounding Context) 팀원이 어떤 것이 일관성을 지녀야 하고, 어떤 것을 독립적으로 개발할 수 있는가를 분명하게 이해하고 이해한 바를 서로 공유할 수 있음. |
| Client
(클라이언트) | - 자체적인 역량을 이용해 설계상의 요소를 호출하는 프로그램 요소 |
| Cohesion
(응집력) | - 논리적인 합의와 의존성 |
| Command
(명령) | - 시스템에 특정 변화를 초래하는 연산
의도적으로 부수효과를 만들어 내는 연산 |
| Conceptual Contour
(개념적 윤곽) | - 도메인 자체의 근원적인 일관성
즉, 모델에 개념적 윤곽이 반영될 경우 설계가 변화를 더욱 자연스럽게 수용하도록 기여함. |
| Context
(컨텍스트) | - 단어나 문장이 해당 의미를 결정한다고 보여지는 환경
(Bounded Context도 참조할 것) |
| Context Map
(컨텍스트 맵) | - 프로젝트와 관련된 Bounded Context 및 Bounded Context와 모델 간의 실제 관계를 표현한 것 |
| Core Domain
(핵심 도메인) | - 사용자의 목적에 중심적인 역할을 수행해서 애플리케이션을 차별화하고 가치 있게 만드는 모델의 특징적인 부분 |
| Declarative Design
(선언적 설계) | - 특성에 대한 정확한 기술이 실제로 소프트웨어를 제어하는 수단이 되는 프로그래밍의 한 형태
실행 가능한 명세 |
| Deep Model
(심층 모델) | - 도메인 전문가의 주된 관심사와 도메인과 가장 관련이 깊은 지식을 정확하게 표햔한 것.
심층 모델은 도메인의 피상적 측면과 초보적인 수준의 해석을 탈피함 |
| Design Pattern
(디자인 패턴) | - 특정 컨텍스트 내의 일반적인 설계 문제를 해결하고자 조정된 관련 객체와 클래스를 기술한 것 |
| Distillation
(디스틸레이션) | - 더욱 가치 있고 유용한 형태로 본질을 추출할 목적으로 혼합물에서 구성요소를 분리하는 과정
소프트웨어 설계에서는 모델 내의 핵심적인 측면에 대한 추상화, 또는 Core Domain이 부각되도록 큰 시스템을 분할하는 것을 의미 |
| Domain
(도메인) | - 지식이나 영향력, 또는 활동의 영역 |
| Domain Expert
(도메인 전문가) | - 소프트웨어 프로젝트에서 자신의 활동 범위가 소프트웨어 개발이 아니라 애플리케이션 도메인인 구성원.
도메인 전문가는 단지 불특정 다수의 소프트웨어 사용자가 아니라 주제 영역에 관해 깊이 있는 지식을 갖추고 있음. |
| Domain Layer
(도메인 계층) | - Layered Architecture 내에서 도메인 로직을 책임지는 설계와 구현에 해당하는 부분
도메인 계층에는 도메인 모델에 대한 소프트웨어적 표현이 위치함 |
| Entity
(엔티티) | - 근본적으로 속성이 아니라 연속성과 식별성의 맥락에서 정의되는 객체 |
| Factory
(팩토리) | - 클라이언트를 위해 복잡한 생성 로직을 캡슐화하고 생성된 객체 타입을 추상화하는 메커니즘 |
| Function
(함수) | - 식별 가능한 부수효과 없이 결과를 계산하고 반환하는 연산 |
| Immutable
(불변성) | - 생성 후 식별 가능한 상태가 결코 바뀌지 않는 특성 |
| Implicit Concept
(암시적 개념) | - 모델이나 설계의 의미를 이해할 필요성은 있으나 결코 언급되지 않는 개념 |
| Intention-Revealing Interface
(의도를 드러내는 인터페이스) | - 클래스와 메서드, 그리고 다른 구성요소의 이름이 그것을 만든 최초 개발자의 의도와 클라이언트 개발자에게 부여되는 가치를 전달하는 설계 |
| Invariant
(불변식) | - 메서드 실해 중이나 아직 커밋되지 않은 데이터베이스 트랜잭션 중과 같은 특별히 일시적인 상황을 제외하고는 항상 참임을 보장받는 특정 설계 요소에 대한 Assertion |
| Iteration
(반복주기) | - 프로그램이 되풀이해서 작은 단계에 걸쳐 향상되는 과정. 또한 그러한 단계 중 하나 |
| Large-Scale Structure
(대규모 구조) | - 전체 시스템에 대한 설계 패턴을 수립하는 일련의 고수준 개념이나 규칙, 또는 두 가지 모두를 의미
시스템을 넓은 안목에서 논의하고 이해할 수 있게 하는 언어 |
| Layered Architecture
(계층형 아키텍처) | - 소프트웨어 시스템의 관심사
특히 도메인 계층을 격리해서 관심사를 분리하는 기법 |
| Life Cycle
(생명주기) | - 객체가 생성에서 소멸까지 취하는 일련의 상태로서, 일반적으로 하나의 상태에서 다른 상태로 변경될 때 무결성을 보장하는 제약조건을 포함
시스템과 다른 Bounded Context 간의 Entity 이동을 포함할 수 있음 |
| Model
(모델) | - 도메인의 선택된 측면을 기술하고 해당 도메인과 관련된 문제를 해결하는 데 사용할 수 있는 추상 체계 |
| Model-Driven Design
(모델 주도 설계) | - 소프트웨어 요소의 일정 부분이 모델의 요소에 밀접하게 대응하는 설계
또한 서로 긴밀한 관계에 있는 모델과 구현을 함께 개발하는 과정 |
| Modeling Paradigm
(모델링 패러다임) | - 도메인에 담긴 개념을 찾아내는 특정 형식을 의미하며, 그러한 개념에 대한 소프트웨어적 유사물을 만들어 내는 도구와 결합됨 |
| Repository
(리파지터리) | - 객체 컬렉션을 흉내 내며, 저장/조회/검색 행위를 캡슐화하는 메커니즘 |
| Responsibility
(책임) | - 작업을 수행하거나 정보를 알아야 할 의무 |
| Service
(서비스) | - 캡슐화된 상태가 없으며, 모델에 홀로 존재하는 인터페이스로 제공되는 연산 |
| Side Effect
(부수효과) | - 의도적인 갱신 여부나 고의적인 갱신 여부와는 관계없이 연산의 결과로 발생하는 모든 식별 가능한 상태 변화. |
| Standalone Class
(독립형 클래스) | - 시스템의 기본 기능과 기본 라이브러리를 제외하고 다른 어떤 것도 참조하지 않은 상태에서 이해하고 테스트할 수 있는 클래스 |
| Stateless
(무상태) | - 클라이언트가 해당 요소의 이력에 상관없이 그것의 모든 연산을 사용할 수 있는 설계 요소의 특성
상태가 없는 요소는 전역적으로 접근 가능한 정보를 사용할 수 있고, 심지어 그러한 전역 정보를 변경할 수도 있으나 해당 요소의 행위에 영향을 주는 비공개 상태를 유지하지는 앟음 |
| Strategic Design
(전략적 설계) | - 시스템의 큰 부분에 적용되는 모델링과 설계 결정
이러한 결정은 전체 프로젝트에 영향을 주며 팀 수준에서 내려야 함 |
| Supple Design
(유연한 설계) | - 심층 모델에 내재된 힘을 클라이언트 개발자에게 맡겨 예상되는 결과를 효과적으로 보여주는 명확하고 유연한 표현을 만드는 설계
마찬가지로 중요한 점은 유연한 설계가 동일한 심층 모델을 활용해 구현자가 설계 자체를 본떠 다른 형태로 만들어 새로운 통찰력을 쉽게 받아들일 수 있다는 것임 |
| Ubiquitous Language
(보편 언어) | - 도메인 모델에 따라 구조화되어 모든 팀원이 소프트웨어와 팀의 모든 활동을 연계하는데 사용하는 언어 |
| Unification
(단일화) | - 각 언어가 모호하지 않고 어떠한 규칙도 모순되지 않는 모델의 내적 일관성 |
| Value Object
(값 객체) | - 일부 특징과 속성을 기술하지만 식별성 개념이 없는 객체 |
| Whole Value
(전체 값) | - 단 하나의 완전한 개념을 모델화한 객체 |