도메인 주도 설계 첫걸음.

복습이 필요할 당시 나를 위해 끄적끄적,,,

 

 

● 도메인 주도 설계: 비즈니스 도메인이 소프트웨어 설계 의사결정을 주도하게 하는 것

● 핵심 하위 도메인: 경쟁사와 차별화하기 위한 회사의 전략

● 지원 하위 도메인: 업계 경쟁에 영향을 주지 않으므로 오픈소스 활용
(기본적인 ETL 작업 및 CRUD 인터페이스)
- 외부 솔루션을 연동하는 것보다 자체 솔루션을 구현하는 것이 편하다면
- 정교한 디자인 패턴이나 고급 엔지니어링 기술이 필요 없다.

● 일반 하위 도메인: 복잡하지만 경쟁 우위를 수반하지 않으므로 이미 검증된 기존 솔류션 사용하는 것이 좋음

● 도메인 전문가: 소프트웨어의 "비즈니스 도메인"에 대한 권위자
(요구사항 수집하는 분석가나 설계자가 아니다)

● 유비쿼터스. 일관성: 오직 하나의 의미를 가져야 한다.

● 모델: 실제 세계의 복사본이 아닌 복잡한 시스템을 이해하는 데 도움을 주기 위한 구조

● Value Object: 불변이다, 엔티티 속성을 설명한다.

● 애그리게이트 + Value Object = 트랜잭션의 경계

● 애그리게이트 = 엔티티
- 강력한 일관성이 필요한 정보만 포함(변경 요청을 검사해서 비즈니스 규칙에 위배되지 않게 한다)
- 모든 객체는 같은 트랜잭션 경계를 공유하기에 커지는 만큼 성능과 확장 문제 발생
- 자신의 메서드를 통해서만 수정한다. (자유도를 줄여라)  
- 내부 비즈니스 규칙과 불변성, 로직의 복잡성을 감싸는 개별적 비즈니스 기능 단위

● 도메인 이벤트: 애그리게이트의 퍼블릭 인터페이스 일부

● 도메인 서비스: 비즈니스 로직에서 사용되는 상태가 없는 객체(stateless object)

● 프레젠테이션 계층: 웹UI, CLI, REST API

● 스트랭글러 패턴: 특정 부분의 기능을 새로운 애플리케이션 및 서비스로 점진적으로 교체하는 기법

● 마이크로서비스
- 바운디드 컨텍스트다
   ㄱ MS는 서비스의 가장 작은 유효한 경계를 정의
    ㄴ 바운디드는 모델 전반의 일관성을 보호하고 가장 넓은 유효한 경계를 정의

●● 시스템의 복잡성 ●● 
제어와 동작 예측의 어려움을 평가하는데 관심을 가져라

●● Tip ●● 
- 바운디드 컨텍스트 설계는 경계를 넒게 해서 시작하라
 -바운디드 컨텍스트는 메뉴(ux) 서비스 중심이 아니다.  
   ㄴ 비즈니스 로직의 "책임 중심"으로 컨텍스트를 분리하라
 -바운디드 컨텍스트는 다른 바운디드 컨텍스트 호출을 경계하며 각각의 자율성을 높여라
- 하위 도메인의 비즈니스 로직이 복잡하면 "도메인 모델 구현"
- 하위 도메인이 복잡한 자료구조를 갖는다면 "엑티브 레코드"(데이터베이스 연산을 객체에서 직접 처리하는 방식)
 - 애그리게이트는 기능이 밀접하게 연관되거나 정책에 따라 연관될 수 있다.


- 설계
1. 컴포넌트의 특성 중 수명주기를 분리할 수 있는지 찾기
2. 모든 컴포넌트가 하나의 모놀리식 코드베이스에 있어도 다른 컴포넌트와 독립적으로 개선/테스트/배포될 수 있는지 확인하라

 

 

아키텍처는 시스템의 기능에 의해 결정되는 것이 아니라 시스템의 비기능적 속성에 의해 결정된다.