도메인 주도 설계 구현

아키텍처

의존성이 영향을 주는 방식을 조정함으로써 전통적인 계층 아키텍처를 개선하는 방법이 하나 있다.
로버트 C 마틴에 의해 제안되었다.

상위 수준의 모듈은 하위 수준 모듈에 의존해선 안된다. 둘 모두 반드시 추상화에 의존해야 한다.

앨리스테이 콕빈은 헥사고날 아키텍처에서 대칭성을 만들어 주는 스타일을 규정했다.

계층 아키텍처를 사용하고 있다고 말하는 많은 팀은 실제론 헥사고날을 사용하고 있다.
의존성 주입이 무조건 헥사고날을 의미하진 않으며, 아키텍처를 만드는 과정에서 자연스럽게 포트와 어댑터 스타일의 방향으로 흘러가게 해줄 뿐이다.

이질적인 클라이언트가 입력을 보낼 수 있도록 해주며, 영속 데이터를 가져오거나
애플리케이션의 출력을 저장하거나 다른 위치로 전송하는 메커니즘을 제공한다.


기능적 요구사항에 따라 애플리케이션 내부를 설계하라

헥사고날을 사용하면 유스케이스를 염두에 두고 설계할 뿐이지 지원되는 클라이언트의 수를 고려하진 않는다.

서비스 설계 원리

서비스는 그 목적과 기능을 하나 이상의 설명 문서에 계약으로써 표현한다.

서비스는 의존성을 최소화하고 오직 서로에 대해서만 알고 있다.

서비스는 그들의 계약만을 계시하고 클라이언트로 부터 내부 로직을 숨긴다.

서비스는 하위 환경과 자원을 제어하며 독립적으로 유지되고 이로부터 서비스는 일관성과 신뢰성을 유지한다.

서비스는 하위 환경과 자원을 제어하며 독립적으로 유지되고 이로부터 서비스는 일관성과 신뢰성을 유지한다.

서비스는 상태관리의 책임을 소비자에게 두며 이는 서비스 자율성을 위한 제어과정이 충돌하지 않도록 하기 위해서이다.

메타데이터로 서비스를 기술함으로써 검색이 가능해지고 서비스 계약을 이해할 수 있는데 이를 통해 서비스는 사용 가능한 자산이 된다.

서비스는 크기나 컴포지션의 복잡성과는 무관하게, 더 대단위의 서비스를 구성하는 일부가 될 수 있다.

1
2

서비스를 SOAP/WSDL 인터페이스의 집합이나 RESTFUL 리소스의 모음으로 바라보는 관점을 선택할 기회를 준다.
이는 정의를 내리겠다는 의도가 아니며, 우리 모두가 동의할 수 있는 가치와 원리를 찾으려는 시도다.

DDD를 사용할때의 목표는 언어적으로 잘 정의된 완벽한 도메인 모델을 바탕으로 바운디드 컨텍스트를 생성하는것.