박종복
669
2021-02-15 10:30:40
1
255

Bounded Context 어떻게 식별할 것 인가?


DDD에서 가장 중요한 부분이지만 가장 모호한 Bounded Context 식별방법에 대해 설명해 봅니다.

* 주의: 본 글은 개인적인 의견이 다수 포함된 글입니다.

1. Event Storming

Domain 전문가들이 모여서 모델 대상 개체를 식별하는 특별한 Workshop.

- Domain 전문가라면 Command, Domain Event, Aggregate등 핵심요소 식별이 어렵지 않겠지만, Bounded Context는 여전히 식별하기 모호하다.

- 소프트웨어 개발공정상 Event Storming과 비슷한 공정은 ISP+BRR 컨설팅 프로젝트 또는 분석단계 일 것이다.

- Event Storming은 조직의 구조를 정하고 각 조직간에 R&R을 정의하는 한다는 관점에서 접근해야 한다.

* Conway's law: 소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다.

- 그래서 중요한건 조직의 구조(Bounded Context)와 R&R에 대한 의사결정을 가진사람들과 Domain 전문가들이 참여해야 한다.

- 프로젝트팀의 역할은 비지니스 컨설턴트 또는 분석가의 입장에서 참여해야 한다.

- 단일 조직이 단일 Bounded Context에 의존하는게 가장 이상적인 설계. (소프트웨어 변경영향도가 최소화 됨)

2. 현실적인 문제점

- 대부분의 SI프로젝트에서는 의사결정권자 참여하지 않고 심지어 Domain 전문가도 없이 프로젝트팀만 모여서 Event Storming을 해야 한다더라 해서 그냥 포스트잇만 붙여될 가능성이 크다.

- 그래서 현실적인 대안은 현재 구성된 조직의 구조를 Bounded Context로 설정해놓고 그위에 모델대상 개체를 식별하는 방법일 것이다.

3. 조직의 구조와 Bounded Context 차이점

Bounded Context는 수평적으로 나누어 지지만 조직의 구조는 계층적인 구조

- 최하위(Leaf) 조직은 대부분 비지니스를 가장 많이 실행하는 조직일 가능성이 크므로 1차적으로 Bounded Context 식별대상 이다.


- 반대로 동일한 비지니스를 여러개 조직이 나누어서 수행하는 경우가 있다 이런경우는 소프트웨어 입장에서는 처리능력을 확장(Scale)을 의미하므로 상위조직이 Bounded Context 식별대상이 된다.


- 동일한 조직의 구성원 일부이지만 독립적으로 수행하는 비지니스가 많다면 별도의 Bounded Context 식별 대상이 된다.

- 또한 특별한 비지니스 수행이 없이 정치적으로 만들어진 조직이라면 일단 Bounded Context 식별대상에서 제외해야 한다.

0
  • 댓글 1

  • GSGfactory
    370
    2021-02-15 13:31:09

    제가 DDD에 대해 항상 아쉬워하는 부분이네요.


    결국은 "상황에 맞게", "잘" 정하자. 아닌가요?

  • 로그인을 하시면 댓글을 등록할 수 있습니다.