도메인 주도 설계 구현
바운디드 컨텍스트 통합(Integrating Bounded Contexts)
통합의 기본
- 하나의 바운디드 컨텍스트가 애플리케이션 프로그래밍 인터페이스(API)를 노출하고 다른 바운디드 컨텍스트가 원격 프로시저 호출(RPC)을 통해 해당 API를 사용하는 방법
- 메시징 메커니즘을 사용하는 것
- RESTful http를 사용하는것 - URL로 구분된 리소스를 교환하고 수정하는 것 RPC랑은 다르다.
분산시스템은 근본적으로 다르다.
분산 컴퓨팅 원칙
- 네트워크는 신뢰할 수 없다.
- 언제나 지연이 있을 수 있고 많을 수도 있다.
- 대역폭은 무한하지 않다.
- 네트워크가 안전하다고 가정하지 말라.
- 네트워크의 위상(topology)는 변화한다.
- 정보와 정책은 다수의 관리자에 걸처 퍼져있다.
- 네트워크 전송은 비용이 든다.
- 네트워크는 다양성을 갖고 있다.
시스템에 걸친 정보의 교환
정고를 교환하는데 사용할 구조를 생성하는 몇가지 방법
- 객체를 이진포멧으로 직렬화하고 컨슈머 측에서 다시 역직렬화하는 방법
- 몇가지 표준 중간 포멧을 사용하는 방법(json, xml, Protocol Buffers) 이중 일부는 비용에 영향을 미칠수도 있다.
- RFC 4288의 가이드라인을 사용해 커스텀 미디어 타입을 등록하는 방법
레스트풀 리소스를 사용한 통합
풍부한 레스트풀 이소스를 URI를 통해 바운디드 컨텍스트가 제공된다면 오픈 호스트 서비스의 한 종류 이다.
레스프풀 리소스의 의존성이 컨슈머 자율성에 방해가 될수도 있다.
부패 방지 계층을 통해 REST 클라이언트의 구현
메시징을 사용한 통합
메시지 기반의 접근법을 사용한 통합은 한 시스템이 의존적인 스스템으로 부터 좀 더 높은 수준의 자율성을 달성할 수 있도록 해준다.
DDD를 활용해 시스템을 자율성 있게 만드는 한가지 방법은 도메인 이벤트의 사용이다.
한시스템에 뭔가 중요한 일이 발생하면 이와 관련된 이벤트를 만든다. 각스스템 안에 이런 이벤트가 서너개 이상 있을수 있고
이런 각각의 이벤트를 기록하기 위해 여러분은 고유한 종류의 이벤트를 생성한다.
서비스에 책임이 강해진다.
장기 실행 프로세스와 책임의 회피
어떻게 해야 프로세스가 끝까지 실행된다고 확신할수 있을까?
프로세스 상태 머신과 타임아웃 트래커
- 적어도 한번은 메시지의 전달이 보장되기 때문에 메시지를 익스체인지로 보냈다면 리스터에 도달하는것은 시간문제이다.
- 협업 컨텍스트 오퍼레이션이 멱등하게 만들어야 한다.
- 메시지 발송에 문제가 있다면 성공할때까지 재발송을 시도하도록 관리 되야 한다.