[Server] DDD(Domain-Driven Design) 도메인 주도 설계

정의

유사한 업무들을 묶어 중심에 놓고 설계하는 방식

프로젝트 단위의 바운디드 컨텍스트가 생긴다.

장점

명시적인 강제 언어 경계가 생긴다.

컨텍스트 별 독립적인 발전이 가능해진다.

인터페이스에 기반한 컨텍스트 간 통신이 이뤄진다.

언어가 중요한 요소!

언어의 경계를 얼마나 잘 나누느냐가 DDD의 성패 결정

Conway's Law

우리가 만드는 시스템은 조직의 모양에 따라간다.

비지니스 도메인 별 팀을 꾸리게 된다면 자연스럽게 그에 맞는 바운디드 컨텍스트를 가진 프로세스가 제작될 가능성이 높다.

분산화된 데이터 관리

통일화된 DB를 가진다면 join의 유혹에 빠지기 쉽다.

서비스별 물리적 논리적 DB를 가지게 된다면 경계를 치기가 더욱 유리하다.

진화하는 설계

각각의 프로세스가 개별로써 진화하고 발전할 수 있도록 해야한다.

MSA로 가는 중 생긴 문제

데이터를 가져오는데 성능적 이슈가 있다.

커뮤니케이션에 대한 부담.