DDD : 다른 도메인 동작/논리를 유발하는 바운드 컨텍스트 동기화

Question

현재 몇 가지 제한된 컨텍스트로 구성된 DDD 시스템에서 작업하고 있습니다. 그 중 2는 다음과 같습니다

1. 상황 "계정 관리" : 만 직원 여기에 작동 할 수 있습니다. 아이디어는 고객 계정 (주소, 전화 번호, 연락처 등)을 관리하고 고객의 계정을 확인하는 것입니다 (기본적으로 고객이 제공 한 데이터가 유효한지 확인하는 것).
2. 상황 "웹 사이트" : 나는 고객으로 로그인 내 데이터 (예 : 내 주소 변경) 여기

이 문제가 편집 할 수있는 사용자는 계정 관리에 로그인

컨텍스트는 정의마다 정의됩니다. 따라서 여기에서 만든 변경 사항은 "데이터가 검증되었습니다"라는 의미에서 "신뢰할 수 있습니다"라고 가정 할 수 있습니다. appservice의 간단한 변형은 다음과 같습니다

class AccountAppService 
{ 
    public function changeAddress(string $accountId, string $address) : void 
    { 
     $account = $this->accountRepository->ofId(new Guid($accountId)); 
     $account->changeAddress(new Address($address)); 
    } 
{ 

이 직원이 주소를 변경 할 때 내가 전화하고있는 appservice입니다. 여기에 흥미롭지 않은 직원이 누구인지 알기 위해 내가 주입/사용하는 IdentityService가 없다는 점에 유의하십시오. 계정 개체가 성공적으로 너무

class Account implements Entity 
{ 
    public function changeAddress(Address $address) : void 
    { 
     $this->address = $address; 
     DomainEventSubscriber::instance()->publish(new AccountAddressChanged($this)); 
    } 
} 

처럼 그 changeAddress() 메서드를 호출 후 AccountAddressChanged 이벤트를 방출 할 것이다 그러나 나는 또한 곧 웹 사이트에서 고객이 편집 데이터로 변경 사항을 반영 할 필요가있다. 나는 "AccountAddressChangedViaWebsite"라는 이벤트를 통해이 비동기를 수행 할 계획이다. 계정 관리 컨텍스트는 해당 이벤트를 구독하고 처리하여 해당 계정을 "확인되지 않음"으로 다시 설정합니다. 그래서 계정 관리 환경의 단순화 된 가입자는 볼 수 있었다 같은 : 이제

class AccountAddressChangedViaWebsiteSubscriber 
{ 
    public function handle(AccountAddressChangedViaWebsite $event) : void 
    { 
     $accountId = $event->accountId(); 
     $address = $event->getAddress(); 
     $this->accountService->changeAddress($accountId, $address); 
    } 
} 

질문 : 직원이 직접 appservice 전화 가입자를 통해 고객. "우리는 고객이 자신의 데이터를 업데이트 한 후 계정을 다시 확인해야합니다"라고 말하면 도메인 개념처럼 들립니다. 도메인 개념은 엔티티 또는 도메인 서비스에 적합하지만 내가 알고있는 애플리케이션 서비스 또는 가입자에게는 적합하지 않습니다.

class AccountAddressChangedViaWebsiteSubscriber 
{ 
    public function handle(AccountAddressChangedViaWebsite $event) : void 
    { 
     $accountId = $event->accountId(); 
     $address = $event->getAddress(); 
     $this->accountService->changeAddress($accountId, $address); 
     $this->accountService->unverifyAccount($accountId); 
    } 
} 

이 약간 이상한 것 같다 가입자에 숨겨져 도메인 로직입니다 : 그것은 다음합니다 (마지막 줄 호출 unverifyAccount()주의) 피해야한다 나에게 의미한다. 나는 이것이 도메인 서비스의 책임이라고 생각하지만 도메인 서비스는 외부 이벤트 (가입자를 통한) 또는 명령에 의해 어떻게 호출되는지 알 것인가?

"Originator"ValueObject의 일종을 전달할 수 있습니다. ValueObject는 직원이든 외부 시스템이든 사용자에게 알려줍니다. 예 :

class OriginatorService 
{ 
    public function changeAddress(Originator $originator, Account $account, Address $address) : void 
    { 
     $account->changeAddress($address); 
     if(($originator instanceof Employee) === false) { 
      $account->unverify(); 
     } 
    } 
} 

여기서는 도메인 서비스에 대한 책임을 위임합니다. 그러나 OriginatorService를 Account 엔티티에 두 배로 배치하는 것이 좋은 해결책일까요? 이 방법을 사용하면 엔터티는 전달 된 originatorService에 요청하여 변경 원인을 확인할 수 있으며 자체를 확인하지 못했습니다.

나는 여기에 DDD 토끼 구멍을 추측 하겠지만, 그런 경우에 당신의 경험/모범 사례는 무엇입니까?

Answer 1

가장 단순한 대답은 "주소"를 보충 고려 사항으로 보편적 인 아이디어로 취급하려고 시도하는 대신 UnverifiedAddress를 모델의 개념으로 소개하는 것입니다.