도메인 주도 설계 및 구현(4)
팩토리(Factory)
팩토리를 사용하는 주된 동기를 생각해봐라
복잡한 객체와 애그리게잇 인스턴스를 생성하는 책임을 객체로 이동시키자.
여기서의 책임은 도메인 모델과 관련이 있진 않지만, 여전히 도메인 설계를 구성하는 한 요소다.
모든 복잡한 조립과정을 캡슐화하고, 클라이언트가 인스턴스화 된 객체의 구체적 클래스를 참조할 필요가
없도록 인터페이스를 제공하자.
전체 애그리게잇을 하나의 조각으로 생성하고, 고정자를 지정하자.
리파지토리(Repository)
애그리게잇 만이 리파지토리를 갖게 된다.
트랜젝션 관리
도메인 모델과 이를 둘러싸는 도메인 계층은 트랜잭션을 관리하기에 올바른 장소가 아니다.
모델과 연관된 오퍼레이션 자체가 트랜젝션을 관리하기에는 일반적으로 그 단위가 너무 작고, 그들의 수명주기에 트랜잭션 영향을 미쳐서도 안된다. 따라서 애플리케이션 객체에서 관리해야 한다.
분산컴퓨팅 원칙
-
네트워크를 신뢰할 수 없다.
-
언제나 지연이 있을 수 있고, 많을 수도 있다.
-
대역폭은 무한하지 않다.
-
네트워크가 안전하다고 가정하지 말라.
-
네트워크 위상(topology)은 변화한다.
-
정보와 정책은 다수 관리자에 걸쳐 퍼져 있다.
-
네트워크 전송은 비용이 든다.
-
네트워크 다양성을 갖고 있다.
– package 위치
외부 연동 서비스 -> infrastructure
내부 연동 서비스 -> application
( 이러한 규칙으로 패키지 및 클래스를 나눠놓고 현재 작업 중인데.. 매우.. 정리가 안된다. 좀더 시행착오를 겪어봐야 될까? 하지만 규모가 있는 서비스도 아니고 조직이 아닌데 도메인 형태로 나누는 것도 역시 낭비일 수 있고. 어렵다.. 항상 간단하게 깔끔하게 잘 동작하는 것이 베스트인데 )
메시지 기반 서버를 구성 할땐 table의 변화에 따른 다운타임이 있다는 것을 인지하고 짧게 가져가기 위해 노력해야 한다.
-> 외부 서버로 메시지를 전송 했을 때 해당 서비스가 다운될 경우도 있으니..
애플리케이션
애플리케이션이란 무엇인가?
결론부터 말하면, 애플리케이션을 핵심 도메인 모델과 상호 교류하며 이를 지원하기 위해 잘 조합된 컴포넌트의 집합을 의미하기 위해 사용하고 있다. 이는 일반적으로 도메인 모델 그 자체와 사용자 인터페이스, 내부적으로 사용되는 애플리케이션 서비스, 인프라적 컴포넌트를 뜻한다.
이 각각 영역에 어떤 것들이 들어가는지는 애플리케이션 마다 다르며, 사용하는 아키텍처가 무엇인지에 따라서도 달라진다.
중요하게 기억해야할 한가지는 프리젠테이션 모델은 서비스나 도메인 모델 주변에서 너무 무거운 짐을 지니고 있는 파사드가 아니라는 점이다.
포털-포틀렛(portal-portlet)
사용자 인터페이스 계층 ㅣ 애플리케이션 계층 / | ＼ 제품: 도메인 계층 토론: 도메인계층 리뷰: 도메인 계층
이벤트소싱
이벤트 소싱은 애그리게잇을 생성한 이후 발생한 일련의 이벤트를 통해 애그리게잇의 상태를 나타내는 데 사용 할 수 있다. 이벤트가 발생한 순서대로 해당 이벤트를 다시 재생한다면, 이벤트를 통해 애그리게잇 상태를 재구축 할 수 있다. 여기서 이런 방식의 접근을 합리화 할 수 있는 전제는 영속성 문제를 단순화 시키고 복잡한 행동 속성에 관한 개념을 포착할 수 있게 해주냐는 점이다.
이벤트 소싱에서 발생된 이벤트는 이벤트 저장소에 저장 된다.
그리고 언제나 이해해야 할 부분인 경험이 많은 개발자의 수는 한정적이다.