도메인 주도 설계 첫걸음 - 11장 진화하는 설계 의사결정

범위

• [Part 3] 도메인 주도 설계 적용 실무 - 11장: 진화하는 설계 의사결정

개념 정리

• 우발적 복잡성: 오래된 설계의 결정으로 발생하는 복잡성

책에서 기억하고 싶은 내용

도메인 변경

핵심에서 일반으로

• 경쟁 우위로 간주했던 것이 모든 경쟁업체가 사용할 수 있는 상품이 된 것

일반에서 핵심으로

• 상용 솔루션을 복잡성을 고려해 내제화하여 경쟁업체보다 경쟁 우위를 확보한 것

지원에서 일반으로

• 사내 솔루션을 버리고 상용 솔루션을 사용

지원에서 핵심으로

• 지원 도메인이 시간이 지남에 따라 비즈니스 로직이 복잡해지고, 회사의 수익성이 개선 된다면 핵심 하위 도메인이 될 징조

핵심에서 지원으로

• 핵심 하위 도메인의 복잡성이 정당화되지 않을 때(복잡성에 비해 수익성이 없는 경우) 발생

일반에서 지원으로

• 상용 솔루션과 통합 과정에서 복잡성 대비 얻는 이점을 정당화할 수 없다고 결정을 내려 다시 사내 솔루션으로 대체

전략적 설계 문제

• 하위 도메인 유형의 변경은 바운디드 컨텍스트에 직접적인 영향을 미치고 결과적으로 전략적 설계 의사결정에도 영향을 준다.

전술적 설계 문제

트랜잭션 스크립트에서 액티브 레코드로

• 트렌잭션 스크립트에서 데이터 작업이 어려워지면 그것을 액티브 레코드 패턴으로 리팩터링하자.
• 복잡한 자료구조를 찾아 액티브 레코드 객체에 캡슐화한다.
• 데이터베이스에 직접 접근하는 대신 액티브 레코드를 사용하여 모델과 구조를 추상화한다.

액티브 레코드에서 도메인 모델로

• 액티브 레코드를 조작하는 비즈니스 로직이 점점 더 복잡해지고 불일치 및 중복 사례가 많아진다면 도메인 모델 패턴을 리팩터링하자.
• 불변 객체로 모델링할 수 있는 자료구조와 관련된 비즈니스 로직을 찾아 벨류 오브젝트의 일부로 만들어라.
• 모든 상태 수정 비즈니스 로직이 그에 상응하는 객체의 경계 내부로 이동할 때 비즈니스 규칙과 불변성을 지속적으로 확인하기 위해 어떤 계층이 필요한지 검토하라. 그 것은 애그리게이트의 좋은 후보다.
• 각 애그리게이트에 대해 루트 또는 퍼블릭 인터페이스의 엔드포인트를 식별한다. 애그리게이트에 있는 다른 모든 내부 객체의 메서드를 private로 만들어서 애그리게이트 내에서만 호출 가능하게 한다.

도메인 모델에서 이벤트 소싱 도메인 모델로

• 애그리게이트 경계가 적절하게 설계된 도메인 모델이 있으면 이벤트 소싱 모델로 전환할 수 있다.

전환에 필요한 과거 이력 생성

• 각 애그리게이트를 위한 대략적인 이벤트 스트림을 생성해서, 변환된 모델이 생성된 이벤트 스트림을 프로젝션해서 원래 구현과 동일한 상태를 나타내게 한다.
• 이 같은 접근 방식을 사용하면 상태 전환의 전체 히스토리를 복구하는 것은 불가능하다.

마이그레이션 이벤트 모델링

• 명시적으로 이벤트를 모델링하는 방법
• 현재 상태로 이어질 수 있는 모든 이벤트를 복구하는 대신 마이그레이션 이벤트를 정의하고 기존 애그리게이트 인스턴스의 이벤트 스트림을 초기화한다.

조직 변화

• 시스템 설계에 영향을 줄 수 있는 또 다른 변화의 유형은 조직 자체의 변화다.

파트너십에서 사용자-제공자로

• 바운디드 컨텍스트 중 하나에 대한 작업이 멀리 위치한 개발 센터로 이동하는 경우

사용자-제공자에서 분리형 노선으로

• 어떤 시점에서는 계속해서 서로의 꼬리를 쫓는 대신 기능을 복제하는 것이 더 비용 효과적일 수 있다.

도메인 지식

• 전략적 설계 관점에서 볼 때 도메인 지식 수준에 따라 바운디드 컨텍스트의 경계를 설계하는 것은 유용한 휴리스틱이다.
• 도메인 지식의 퇴보를 사전에 방지하는 것이 중요하다.

성장

• 성장은 시스템이 건강하다는 신호다.
• 성장에 따른 복잡성을 다루는 기본 원칙은 우발적 복잡성, 즉 오래된 설계의 결정으로 발생하는 복잡성을 식별하고 제거하는 것이다.

하위 도메인

• 다양한 유형의 세분화된 하위 도메일을 식별할 수 있다면 비즈니스 도메인의 본질적인 복잡성을 관리할 수 있는 중요한 통찰력을 보여줄 수 있다.
• 비즈니스 전략 관점에서 가장 중요한 부분에 노력을 투자할 수 있도록 항상 모든 하위 도메인에서 핵심 하위 도메인을 최대한 추출하는 것을 목표로 삼아야 한다.

바운디드 컨텍스트

• 하위 도메인과 마찬가지로 바운디드 컨텍스트의 경계를 때때로 다시 살펴보는 것은 중요하다.
• 특정 문제를 해결하는 데 초점을 맞춘 바운디드 컨텍스트를 추출하여 모델을 단순화할 수 있는 기회를 항상 찾아라.

애그리게이트

• 비즈니스 로직에 따라 강력하게 일관성을 유지할 필요가 없는 데이터까지 포함되면서 애그리게이트가 커진다면 이는 제거해야 하는 우발적 복잡성으로 봐야 한다.
• 비즈니스 기능을 전달 애그리게이트로 추출하면 원래 애그리게이트가 단순해질 뿐만 아니라 잠재적으로 해당 애그리게이트가 속한 바운디드 컨텍스트도 단순해진다.
• 이러한 리팩터링을 통해, 일단 드러나면 하나의 바운디드 컨텍스트로 추출해야 할 숨겨진 모델이 발견될 때가 많다.

결론

• 기업은 경쟁력을 유지하기 위해 끊임없이 진화하고 스스로 재창조하기 위해 노력한다.
• 비즈니스 도메인이 발전함에 따라 하위 도메인에 대한 변경사항을 식별하고 시스템 설계에 조치를 취해야 한다.
• 필요한 경우 현재 비즈니스 전략과 요구사항에 더 잘 맞게 설계를 발전시켜라.
• 조직 구조의 변화가 팀 간의 의사소통과 협력, 바운디드 컨텍스트를 통합하는 방식에 영향을 줄 수 있다는 점을 인식하는 것도 중요하다.
• 소프트웨어 성장은 원하는 유형의 변화지만, 올바르게 관리되지 않으면 시스템 설계와 아키텍처에 치명적인 영향을 줄 수 있다.
  • 그러므로 하위 도메인의 기능이 확장되면 더 나은 설계 의사결정을 내릴 수 있도록 더 세분화된 하위 도메인 경계를 식별하려고 노력하라.
  • ‘여러 방면에 다재다능한’ 바운디드 컨텍스트가 되는 것을 허용하지 마라. 바운디드 컨텍스트에 포함된 모델이 특정한 문제를 해결하는 데 중점을 두고 있는지 확인하라.
  • 애그리게이트의 경계가 가능한 한 작은지 확인하라. 확실하게 일관된 데이터의 휴리스틱을 사용하여 비즈니스 로직을 새 애그리게이트로 추출할 가능성을 탐지하라.
• 성장 주도 복잡성의 징후가 있는지 서로 다른 경계를 지속해서 확인하는 것이다.
• 우발적 복잡성을 제거하고 도메인 주도 설계 도구를 사용하여 비즈니스 도메인의 본질적 복잡성을 관리하라.