도메인 기반 설계는 그렇게 복잡한 도메인이 아닌 경우 유용하고 생산적입니까?

작업중인 잠재적 인 프로젝트를 평가할 때 객체 모델에 도메인 기반 설계 접근 방식을 사용하는 것이 유리할 수 있다고 제안했습니다. 프로젝트에 지나치게 복잡한 도메인이 없으므로 동료가이 문제를 던졌습니다.

DDD는 복잡한 도메인 모델이있는 경우에 유리한 것으로 알려져있다.

내가 잃어버린 것은 도메인의 복잡성을 어떻게 정의합니까? 도메인 모델의 집계 루트 수로 정의 할 수 있습니까? 객체의 상호 작용에서 도메인의 복잡성이 있습니까?

우리가 평가하는 영역은 관련 온라인 출판 및 컨텐츠 관리입니다.

응용 프로그램 동작이라고도하는 비즈니스 논리의 복잡성이 가장 중요한 요소입니다. 두 번째로 중요한 요소는 DDD가 비즈니스와 엔지니어링 팀간에 공유 어휘를 작성하는 것이기 때문에 기술 문제와 해당 문제를 설명하는 데 사용되는 비즈니스 어휘 사이에 차이가 얼마나 큰가입니다.

DDD에 사용 된 일부 패턴은 일반적으로 리포지토리 패턴, 경계 컨텍스트 및 계층 구조와 같은 엔터프라이즈 응용 프로그램 아키텍처에 유용합니다. 이러한 패턴을 사용한다고해서 도메인 기반 디자인을하고있는 것은 아닙니다.

행동이 많지 않은 경우, 즉 대부분 데이터를 저장하고 해당 데이터에 대해 작업하지 않는 경우 해당 도메인 계층을 구축하는 데 훨씬 적은 가치가있을 수 있습니다. 컨텐츠 관리에서 승인하고 게시하는 것이 도메인 메소드가 아닌 시스템에서 플래그로 표시 될 수 있습니다. 그러나 추가 동작을 추가하기 시작하면 풀 도메인 도메인의 적합성이 더 분명해집니다.

콘텐츠 관리에 대해 이야기하고 있다면 DDD의 필요성을 암시하기 시작할 수있는 몇 가지 규칙이 있습니다.

• 날짜 xx / yy / zz까지 스토리가 금지 된 경우 출판을 위해 게시 한 다음 웹에 게시하십시오. 금지가없는 경우 웹에 게시하고 인쇄 가능
• 이 이야기를 유료 구독자에게 즉시 유료 구독자에게 제공하십시오. 2 주 후에 일반 대중에게 공개됩니다.
• 스토리가 작성된 후 수정, 교정 및 승인을 위해 편집자에게 보냅니다. 승인되면 프로덕션으로 보내십시오. 공간상의 이유로 생산이 줄어든 경우 온라인에서 확장 버전을 사용할 수있게하십시오.