도메인 기반 디자인의 도메인 이벤트는 의도를 숨 깁니 까?

Question

도메인 이벤트를 사용하는 것은 DDD 응용 프로그램에 대한 널리 인정되는 관행이지만 나를 위해 까다로운 시나리오가 있습니다.

최근 비즈니스 로직에서 새로운 사용자를 만들 때 해당 사용자가 세 개의 별도 하위 시스템에서 만들어 지도록 요구하는 응용 프로그램에서 작업했습니다. 당신이 트랜잭션 스크립트 방식을 사용한다면 기본적으로는 같은 보일 것이다 :

public void CreateUser() 
{ 
    CreateUserInSystemA(); 
    CreateUserInSystemB(); 
    CreateUserInSystemC(); 
} 

내가 도메인 이벤트를 사용하고 있었다보고 된 접근을하기 때문에 진입 점 같은 것을 보았다 : 다음

public void CreateUser() 
{ 
    CreateUserInSystemA(); 
} 

CreateUserInSystemA 것 사용자가 생성 될 때 도메인 이벤트를 발생시킵니다. 그런 다음 해당 이벤트에 대한 처리기는 시스템 B에서 사용자를 만들고 다른 도메인 이벤트를 발생 시키며 시스템 C에서 사용자를 생성하는 다른 처리기를 실행합니다. DI 컨테이너 등록 중에이 모든 것이 설정되었으므로이 작업은 상당히 복잡했습니다.

그래서 질문은 :

1)이없는이 방법을 효과적으로 도메인 로직을 숨 깁니다합니까? 우리가 실제로하고있는 것을보기 위해 CreateUser 메소드를 살펴 보는 것은 쉽지 않습니다.

2) 시스템 A와 B에서 사용자를 생성하기 만하면되는 새로운 워크 플로가 생깁니다. 따라서 CreateUserInSystemC을 호출하면 안됩니다. 기존 CreateUserInSystemB 구현을 사용하면 도메인 이벤트가 발생하고 CreateUserInSystemC은 아무 관계없이 실행됩니다.

적절한 DDD 방식으로이 시나리오를 처리하는 가장 좋은 방법은 무엇입니까? 응용 프로그램 서비스 계층을 사용해야하고 두 워크 플로에 대해 두 개의 별도 메서드를 노출하고 도메인 이벤트에 기본 흐름을 적용하지 않아야합니까?

Answer 1

나에게 도메인은 독자적으로 하위 시스템입니다. 귀하의 경우 여러 시스템이 상호 연결되어 있습니다. 이 경우 귀하의 이벤트는 도메인 간 이벤트가 아닌 시스템 간 이벤트입니다.

따라서 하위 시스템 간의 관계에 따라 이벤트를 시작하십시오. 각 도메인 (하위 시스템) 관점에서 볼 때, 다른 하위 시스템은 내부에 자체 도메인 모델이있는 통합 계층입니다.

그래서, 질문에 대한 답변은 다음과 같습니다

1) 아니, 접근 방식이 완전히 시스템 통합 관련이 있기 때문이다.

2) 흐름을 변경하려면 하위 시스템이 아니라 통합 동작을 변경해야합니다.

한 가지 더 요점 : 서브 시스템이 의미하는 바는 서비스와 비슷합니다. 각 도메인에는 상호 작용하는 서비스가 있습니다. 그리고 서비스는 대개 상호 작용과 관련이 있습니다 (여러 서비스가있는 SOA 시스템이 구현 예입니다). 또한 각 도메인은 서비스 일 수도 있고 아마도 서비스 계층을 통해 노출 될 수도 있습니다.