공부는 해도 해도 끝이 없구먼

도메인 주도 설계 (DDD)

서비스 분리와 도메인 주도 설계

• DDD는 MSA의 서비스를 식별할 수 있는 도구를 제공
• DDD 중 전략적 설계가 MSA의 서비스를 식별하는데 도움

도메인이란?

• 소프트웨어를 개발하는 대상 영역
• 복잡한 비즈니스나 현실세계의 문제

도메인 주도 설계란?

• 복잡한 현실세계의 문제를 해결할 좋은 SW를 만들기 위한 기법
• 도메인 주도 설계는 도메인의 이해를 최우선시 하는 모델링 기법
• 전문가와 개발자의 커뮤니케이션이 중요
• 도메인과 도메인 모델 그리고 코드를 밀접하게 연관 시킴 (언어의 통일)
• 도메인 모델 - 동일한 관점에서 이해할 수 있고, 공유할 수 있도록 단순화 (다이아그램 사용)
• 코드에 도메인의 의미가 녹아 있도록 구현

DDD의 필요성 : Big Ball of Mud

• 요구사항 추출 -> 분석 -> 설계 -> 구현
• 계속되는 추가 요구사항
• 중요한 것과 덜 중요한, 혹은 중요하지 않은 것들이 하나의 큰 덩어리로 얽히게 됨

• 각 클래스(엔티티)의 의미 파악 어려움

DDD의 필요성 : Big Ball of Mud 원인 by Vaughn Vernon

• 조직에서 SW 설계에 충분한 노력을 들이지 않음
• 개발자는 도메인 보다 기술에 너무 몰두, 많은 문제를 기술적으로만 해결하려 함
• 도메인의 이해 없이 개발자 상상의 나래가 표출됨

전략적 설계

마이크로서비스 도출을 위해서 비즈니스 상 전략적으로 중요한 것을 찾아 중요도에 따라 이를 나눔

전략적 설계의 필요성

• 애자일 프로젝트 관리 시스템을 개발 사례
• 설계 초기에는 핵심이 되는 부분을 설계
• Big Ball of Mud 방지

서브 도메인

• 전체 비즈니스 도메인을 이해 가능한 하위 영역으로 분리 필요
• 전체의 큰 도메인을 분리함
• 핵심 서브 도메인, 지원 서브 도메인 (비즈니스 도메인), 일반 서브 도메인(큰 공수 없는 도메인)으로 분리

바운디드 컨텍스트

• 유비쿼터스 언어로 표현이 됨
• 의미적으로 동일한 맥락의 경계라는 것은 응집도 높은 일을 한다는 것
• 바운디드 컨텍스트 마다 각각 분리된 소프트웨어의 코드 산출

서브도메인과 바운디드 컨텍스트의 관계

• 서브 도메인은 Problem Space
• 바운디드 컨텍스트는 Solution Space
• Problem Space : 해결해야 하는 도메인 -  서브 도메인들의 집합
• Solution Space : 해결책을 실제 구현 - 바운디드 컨텍스트들의 집합
• 보통 하나의 서브도메인은 하나의 바운디드 컨텍스트를 갖는 1:1
• 서브도메인이 하나 이상의 바운디드 컨텍스트가 매핑 가능 (ex). 상품 - 연관상품, 쿠폰, 할인정보 등)

유비쿼터스 언어와 바운디드 컨텍스트의 관계

• 제품 책임자와 도메인 전문가 그리고 개발자 간 언어의 통일이 중요
• SW 개발의 가장 큰 문제 중 하나 (개발언어 x,  사용언어 o)
• 개발자가 아닌 사람도 도메인 모델 및 코드를 보고 이해할 수 있어야 함
• 컨텍스트에 따라 비슷해 보이는 언어들이 실제로는 다를 수 있음
• 각 문맥 별로 상품의 이름을 명확하게 재정의할 필요가 있음

       ex) - 카탈로그 컨텍스트에서의 상품은 Product

             - 재고 컨텍스트에서의 상품은 Stock

             - 주문 컨텍스트에서의 상품은 OrderedItem

결론

개발자가 아닌 사람이 이름만 딱 봐도 무엇인지 알 수 있도록 설계를 하자.