Day1 ( 2020.02.06 )
도메인 주도 설계
내가 만든 소프트웨어가 제대로 된 무언가를, 역할을 할 수 있어야 성능에 대한 이야기를 할 수 있다.
우리가 만든 소프트웨어는 어떤 문제를 해결하기 위해 등장을 하게 되었는지 생각해야 한다.
기존의 개발은 스키마를 먼저 그리고 정규화를 하면서 개발을 하는 데이터베이스에 의존하는 개발을 하고 있다.
테이블을 만들고 정규화를 진행하기 때문에 모델과 스키마가 1:1매핑을 하게 되어 모델이 데이터의 속성을 가지고 있는 역할을 하게 된다.
기획자/도메인 전문가가 생각하는 모델링과 다른 방향으로 서비스를 개발할 수 있게 된다.
내가 가지고 있는 소프츠웨어의 영역, 도메인의 영역에서 생각해야 한다.
도메인 주도 설계 : 내가 갖고 있는 비지니스 로직을 코드에 녹여낸다.
설계를 하고 구축을 하는 것이 아닌 설계와 구축을 계속 반복하는 것으로, 애자일과 xp에 최적화 된 설계방식이다.
- 전략적 설계
- 여기에 많은 에너지를 쏟아야 올바른 전술적 설계와 아키텍쳐가 나올 수 있다.
- 유비쿼터스 언어
- 바운디드 컨텍스트
- 여러개의 바운디드 컨텍스트가 어떻게 이어져있는지 보여주는 컨텍스트 맵
- 컨텍스트간의 관계, 원칙과 패턴
- 전술적 설계
- entity, vo, aggregate, repository와 같은 개념
- 실제 도메인 모델을 코드에 녹여내는 부분
- DDD Light, 빌딩 블록
- 아키텍쳐 ( 유비쿼터스 언어, 유비쿼터스 언어는 전략적 설계에 속하기도 한다. )
도메인이랑 무엇인가
일반적인 요구사항을 소프트웨어 프로그램에 대한 기능성으로 정리하는 영역으로 소프트웨어로 해결하고자 하는 문제 영역이다.
도메인 모델이란 무엇인가
도메인을 개념적으로 표현한 것으로 uml, 클래스다이어그램 같은 모델링이 아닌,
머리속에 있는 비지니스로직과 연관되어 있는 무엇, 형상없이 추상적으로 존재하는 것이다.
도메인 모델은 코드로, 말로, 그림으로 등장할 수 있다.
레거시 코드란
release되는 그 순간이 모두 레거시 이 레거시를 모든 팀원이 더 잘 이해하게 하고, 수정하기 쉽도록 하기 위해 클린코드에 대해 고민하는 것이다.
빈약한 도메인 모델(anemic domain model)
상태와 행위가 있어야 object라고 이야기 할 수 있는데, 데이터만 가지고 있는 object가 생성되면서
서비스레이어에 너무 많은 의존을 하게 된다.
행위를 저장하기 위해 BO(비지니스 오브젝트)가 등장하고 비니지스가 분산, DAO를 호출하는 역할을 하게 된다. domain object와 BO가 모여 big service layer가 등장하게 되고 이는 객체지향 설계를 어렵게 한다.
테스트코드가 없는 레거시를 리펙토링하기 위해서는 테스트코드를 작성해야 한다 단위테스트는 어떤 식으로 로직이 흘러가는지 도메인지식이 반영하며 코드를 처음보는 사람이 그것들을 이해할 수 있게 한다.
Day2 ( 2020.02.13 )
Ubiquitous Language
도메인 생성자(기획자)와 개발자 사이에 있는 언어, 모두가 다 알아 들을 수 있는 언어로
용어가 정의될 때 마다 용어사전에 등록되어야 한다.
효과적인 모델링을 위해서는 모두가 동일한 언어로 이야기 하고 있는지 확인해야 한다.
bounded context
언어와 문맥의 경계 한개의 모델로 모든 하위 도메인을 표현하려는 시도는 올바르지 않다. 한가지 모델에 점점 많은 properties가 생기게 되고, 이는 올바른 객체가 아니다. 도메인마다 사용하는 용어가 다르기 때문에 도메인마다 각각의 모델을 만들어 주는 것이 맞다.
하나의 bounded context를 여러 팀에서 관리하게 된다면 각자 다르게 이해할 수 있기 때문에 결국 context가 분리 될 것이다. 각각의 bounded context는 각각의 개발 환경을 가질 수 있거 이것이 곧 MSA 가 되는 것이다.
누가 봐도 분리가 가능하거나, 동음이의어가 등장하는 순간 context의 분리가 가능하다. ( menu / menu product )
context map
컨텍스트들은 각각 상호간의 교류가 발생하게 되고, 그것을 도식화 한 것을 context map 이라고 부른다. up-stream ( 데이터를 제공하는 ) : api 공개, 이벤트를 publishing down-steam ( 데이터를 받는 ) : api 사용, 이벤트를 subscribing
메뉴는 주문 테이블에 대한 내용을 가질 필요가 없고 주문테이블은 메뉴의 정보를 알아야 한다. 하류는 상류를 알아야 한다.