4. History by Eric Evans
1. 고객 송장 발급 모듈을 담당하던 팀에서 “Charge(요금)” 객체를 구현하려함.
2. 다른팀에서 이미 그 객체를 구현했다는 사실을 알고, 재사용함.
3. 객체에 “지출 코드”가 없다는 것을 확인 후, “지출 코드＂속성을 추가함.
4. 객체에 “기입 금액” 속성을 “납입 금액”으로 부를 계획으로 속성의 이름을 변경함.
5. History by Eric Evans
5. 기존의 내용을 혼란스럽게 하지 않고, 객체를 원하는 형태로 만듬
6. 애플리케이션 모듈은 동작함.
7. 며칠 후, “Charge(요금)”객체를 사용하기로 했던 청구서 결제 어플리케이션 모듈에서
에러가 발생함.
8. 유효성 검증에 필요한 기본값을 입력함에도
“공제율“ 필드에 값이 들어있지 않은 “Charge”가 나타남.
6. 가장 기본적인 MODEL 요구사항
내적으로 일관성을 유지하고 모델의 용어는 언제나 의미가 동일해야 함
모델에는 어떤 모순되는 규칙도 없어야 함
각 용어가 모호하지 않고 모순되는 규칙이 없는 모델의 내적 일관성 : 단일화(Unification)
단일화가 없는 모델은 아무런 의미가 없다.
7. Unification
모델의 주요부분을 밀접하게 단일화하는 수단이 필요
이는 의식적인 설계 결정, 구체적인 프로세스를 거쳐서만 달성 가능
“대규모 시스템의 도메인 모델을 완전하게 단일화 한다는 것은
타당하지 않거나 비용대비 효과적이지 않을 것”
by Eric Evans
9. Context
모델은 컨텍스트에 적용된다.
코드의 특정 부분일수도, 개별팀이 수행하는 업무일 수도 있다.
모델 컨텍스트 : 모델에서 사용된 용어를 특정한 의미로 의사소통하기 위한 조건의 집합
컨텍스트를 명확하게 만들려면 프로젝트와
산출물(코드, 데이터베이스 스키마 등)을 모두 살펴봐야한다.
11. Eric Evans 의 분석
문제는 서로 다른 모델을 보유했지만, 그것을 알아차리지 못함
이를 탐지하는 프로세스 조차 마련돼 있지 않았음
자신들만의 맥락에서만 유효한 “Charge(요금)” 속성을 대상으로 가정을 세웠던 것.
이러한 모순점을 해결하지 않고 코드를 결합하면 신뢰할 수 없는 SW가 만들어짐
12. Bounded
Context
유요한 모델을 식별하고, 각 Bounded
Context를 정의
각 Bounded Context에 이름을
부여하고 이 이름을 Ubiquitous
language에 기록
서로 다른 컨텍스트에 대해서는 용어,
개념과 규칙, 유비쿼터스 랭귀지에
포함된 독특한 표현방식에 차이를
보이는 서로 다른 모델을 적용한다.
13. Bounded Context
팀 구성원이 어떤 부분에서 일관성을 지녀야하고
다른 context와는 어떤식으로 연관되어 있는지를
서로 명확하게 이해할 수 있게 특정 모델의 적용 범위를 제한한다.
이 경계 안에서는 모델을 엄격하게 일관된 상태로 유지하고
경계 바깥의 이슈 때문에 초점이 흐려지거나 혼란스러워 져서는 안된다.
14. Bounded
Context 장점
컨텍스트 안에서 업무를 진행하면
얻게되는 장점 : 명확함
컨텍스트 밖에서 업무를 진행하면
얻게되는 장점 : 자유로움
“실질적 이득은 비공식적인 정보공유가
위험하다는 사실을 인지하는 것“
By Eric Evans
16. Bounded Context 안의 균열 징후
1. 같은 개념을 나타내는
두개의 모델요소와 구현이 존재하는 경우 (중복개념)
2. 같은 모델을 얘기하고 있다고 생각하지만
실제로 그렇지 않은 경우 (허위 동족언어)
17. Continuous
Integration
내부적으로 개념적 균열이 발생할 때,
빨리 포착하고 정정 할 수 있을 정도로
컨텍스트 내의 모든 작업을 빈번하게
병합해서 일관성을 유지하는 것
모델 개념의 통합은 구현을 통합하는
방법을 좀 더 용이하게 하고,
구현통합은 모델의 유효성과 일관성을
입증하고 발생한 균열을 드러낸다.
18. Continuous Integration 프로세스
구현 통합
1. Ubiquitous Language를 지속적으로 다듬는 것
2. 단계적이고 재생 가능한 병합/ 빌드 기법
3. 자동화된 테스트
모델 개념 통합
모델과 앱에 관해 논의할 때 Ubiquitous Language를 지속적으로 사용
20. Context Map
서로 다른 컨텍스트를 연결해야 하는 경우,
컨텍스트는 서로에게 스며드는 경향이 있다.
번역에 대한 윤곽을 명확하게 표현하고
컨텍스트 간에 공유해야 하는 정보를 강조해 서술
Map 은 특정한 형식으로 문서화할 필요가 없지만,
모든 인원이 경계가 어디에 위치하는지 알아야함
21. Context Map
프로젝트 관리와 소프트웨어 설계 영역사이에
걸쳐있는 개념
기능과 데이터는 번역과정을 거쳐 통합해야 한다.
모델과 모델이 만나는 경계지점을 서술
항상 현재 상태 그대로의 상황을 표현한다.
각 컨텍스트의 현재 영역을 나타내는 지도를
작성한다.
번역은 컨텍스트 밖에 존재하는게 좋다.
22. Context Map
서로 다른 컨텍스트 간의 관계를 정의하고
프로젝트 상의 모든 모델 컨텍스트를 아우르는
전체적인 시야를 만들면 혼란을 줄일 수 있다.
Map은 발견한 관계를 서술하기만 한다.
균열을 발견했다면?
지도에 모른다고 적고, 거기서 서술을 중단하라.
혼란스러운 지점을 설명하고, 명확한 context map을 보유하기 전까지는
명백하게 드러난 모순만 변경한다.
23. Context 경계에서의 테스트
컨텍스트의 경계에 존재하는
번역의 미묘한 차이와 낮은 수준의 의사사소통을
보완하는데 기여한다.
테스트는 경보알람 역할을 할 수 있고,
통제할 수 없는 모델의 세부사항에 의존할 때,
안심할 수 있게 만들어 준다.
