DDD 고수님들 질문이 있습니다.

Question

multiple aggregates을 핸들링 하거나, multiple persistent storages를 핸들링 하면서 이벤트 생성시 구현 하는 Outbox pattern에 대해서,해당 Outbox message테이블은 특정 aggregate에 종속되지 않는 형태인 것으로 보이는데요, 이 경우 DDD에서 일반적으로 제시하는 두가지 원칙을 위배하는 것처럼 보여서 질문드려요. 첫번째, The recommendation in DDD is that an aggregate root should not hold references to another aggregate root.두번째,When two or more Aggregates have at least some dependencies on updates, use eventual consistency.Outbox를 적용하면 실질적으로, 특정 aggregate에 대한 reference를 내재하고, 그것이 pull 혹은 push될때 참조되는 값이 되므로 첫번째 원칙이 위배되고, outbox자체가 특정 aggregate의 consistency boundary의 일부라고 할 수가 없을 것 같아서, 이 또한 두번째 원칙에 위배되는 것으로 보여요. 물론 원칙이 실용성을 이길수없다(practicality beats purity)라고는 생각하지만 ㅎㅎ 혹시 다른 견해가 있으실까 싶어 질문올립니다.

guyv · Answer

아무것도 몰라서 chatgpt 한테 물어봤어요(말하다 끊겨서..다시 물어봤는데)무슨말인지는 모르겠네요..

박종복 · Answer

Outbox pattern와 DDD는 직접적인 연관성이 없는 걸로 보입니다. 굳이 따지자면 EDA와 관련있다고 보입니다. 물론 DDD&#43;EDA 할 수도 있겠죠. 그렇다면 message table이 DDD 설계시에 다루어야 할 데이터인가로 바라본다면 제가 보기엔 아니라고 봅니다. 도메인(소프트웨어로 해결하고자 하는 영역)의 필수요소가 아니라 데이터베이스의 메타데이터와 유사한 성격의 데이터에 해당한다고 봅니다. 논리적 설계(DDD) 에서 물리적 설계(EDA, MSA ...)로 확장되면서 발생되는 부산물 중에 하나라고 봅니다.그래서 굳이 DDD와 충돌을 따질 필요성이 없다고 봅니다.

chytonpide · Answer

Outbox pattern 이 정확하게 뭘 의미하는지 모르겠지만, 일종의 메카니즘으로 보이고 DDD에서 말하는 consistency boundary 와는 관계가 없어보입니다. 글로벌 트랜젝션에 대한 여러가지 메카니즘이 있는데 Outbox pattern은 MSA에서 자주 사용되는 메카니즘 같습니다. aggregate의 consistency boundary를 잘 정의한 후에, 일반적인 비동기 메세징 메카니즘을 사용할지 아니면 Outbox pattern 이 적용된 메카니즘을 사용할지는 별개의 선택의 문제인 것 같아요. 둘중 어떤 메카니즘을 사용할지가 aggregate의 consistency boundary를 바꾸지는 않을 것 같습니다. 예를 들자면, 메세지 브로커를 사용해서 결과적 일관성을 만든다고 친다면, 에그리게잇의 상태 변경과 영속화, 이벤트 발행까지 하나의 트랜잭션으로 묶입니다. 시스템을 사용하는 유저가 리소스 A에 대한 오퍼레이션을 실행해서 실행이 완료 되었다고 결과를 받고, 리소스 A와 관련된 어떤 리소스 B에 대한 요청을 이어서 했을 경우, 리소스 A와 A와 관련된 리소스 B가 결과적 일관성을 가지도록 설계되었다면 오퍼레이션에 의해 발행된 이벤트가 아직 적용되지 않은 B를 받을 수 있습니다. 이에 대해서, 만약 리소스 B가 A에 대한 오퍼레이션으로 생성되는 리소스라면, 생성이된 리소스 B를 얻을때 까지 polling을 할 수도 있고, B가 이미 존재하는 리소스라면 상태가 언제 변경되었는지 modified time 이나, 반영된 이벤트를 보고 polling을 할 수도 있을것 입니다. 이 polling은 API 클라이언트 측에서 할 수도 있고, controller에서도 할 수 있겠지요. 여기에 Outbox pattern 을 적용하면 이러한 polling을 할 필요가 없어지는 것 이겠지요. consistency boundary 는 다르게 정의 되어도,polling을 해결하기 위해 이런 메카니즘을 도입할 수 도 있고, 보안과 같은 민감한 리소스와 관련된 오퍼레이션에 이 메카니즘을 쓸 수도 있을 것 같습니다. (또는 하나의 코드베이스에 있어야 하는것이 어떠한 이유로 다른 코드베이스에 존재할때 이것들을 하나의 트랜잭션으로 묶고 싶다던가..)

DDD 고수님들 질문이 있습니다.

3개의 답변

#eda 목록