첫번째 파트인 Introduction에서는 세가지 주제를 다루겠습니다.
- What is DDD all about?
- How do we get started?
- What should we avoid in DDD?
그럼 렛츠고!
1. What Is DDD All About?
DDD는 복잡하고 발전하는 모델을 가진 소프트웨어 프로그램의 개발에 적합하다. (e.g. CRUD 어플리케이션은 아님)
대충 요약하자면, DDD는 Technical Experts (서버 개발자?)와 Domain Experts(사용자, 클라이언트)간의 협력에 중점을 둔 개발 방법론이다. 그래서 기술적인 것 보다 사용자에 더욱 중점을 두어야한다.
2. How Do We Get Started?
위에서도 말했듯이 사용자 - 도메인 전문가에 더욱 집중해야한다. 도메인 전문가인 사용자와 대화를 하기위한 가이드라인을 복습해보자.
가이드 라인!
- Learning about the problem domain, i.e. the specific problem the software you’re working on is trying to solve. Look at the big picture of the current business process.
- Breaking the domain into sub-domains.
- Focusing on one sub-domain at a time with the domain expert , and always use ubiquitous language to define working out terminology * ubiquetous language - ???
- Creating a bounded context between sub-domain. Again, ubiquitous language should always be used throughout the bounded context, from conversations to code, in the diagram, on the whiteboard, in the design document, team discussion, etc. The point is to use the bounded context everywhere. * bounded context - ???
- Ideally, there will be a different team, codebase, and database for each bounded context.
- Since everyone is working for their bounded context, so they are free to change anything within their context.
- For all cross-cutting concerns those are shared between bounded context (we call it shared kernel), any changes should be known and agreed between all team in every bounded context.
- Always stay focused on the domain’s behaviors rather than domain’s state (favor a rich model over an anemic model). * rich model - ??? * anemic model - ???
요약하자면
- ubiquitous language 써라
- 도메인을 서브 도메인으로 쪼게고 bounded context를 부여해라
- boundary를 정의해서 서브도메인은 그 안에서만 생각해라
- bounded context 간에는 interfaces/ crafted software contract로 커뮤니케이션해라
3. What Should We Avoid in DDD?
DDD로 개발할때 주의 사항을 생각해보자!
아래와 같은 행동은 하면 안된다!
1) Problem Domain을 모델링 할때 Data-Centric한 접근하기
보통 개발자나 구조 설계자가 디자인을 처음 할때 data modeling으로 시작한다. DDD를 한다면 이런 마인드셋을 바꿔야한다. Data는 아무 의미가 없고 Data에 적용되는 logic이 Data에 의미를 부여한다.
따라서 data가 아니라 context와 logic으로부터 domain modeling을 해야한다.
2) Core Concept이 아닌 Entity, Value Object, Services, Factories 등에 집중하기
Entity, Value Object, repository 이런애들은 ubiquitous language, bounded contexts, 그리고 interface/crafted software contract가 없이는 아무 의미가 없다. 저런 구현 디테일에 집중하면 anemic한 model이 될 가능성이 높다.
3) 구현에 포괄적이고 개발자만 알아먹는 용어 써먹기
save, update, delete, handle. manage와 같은 단어를 쓰면 안된다.
대신에 더 도메인에 특화된 용어를 쓰자 (e.g. join?)
4) DB 트랜젝션 처리를 믿고 비즈니스 처리나 트랜잭션 관리는 대충하기
DDD에서는 DB 트랜젝션 보다 비즈니스 트랜잭션이 더 중요하다.
실생활에서 우리는 DB 트랜잭션은 모르지만 비즈니스 트랜잭션은 안다.
비즈니스 트랜잭션이 더 큰 (긴 시간의) 트랜잭션을 다루므로 비즈니스 트랜잭션에 집중하면 DB 트랜잭션은 신경도 안써도 된다. 즉 리얼 월드에 더욱 집중하자.