O Design Orientado a Domínio é útil / produtivo para domínios não tão complexos?

Ao avaliar um projeto em potencial no trabalho, sugeri que poderia ser vantajoso usar uma abordagem de design orientada a domínio para seu modelo de objeto. O projeto não tem um domínio excessivamente complexo, então meu colega de trabalho jogou isso para mim:

Já foi dito que o DDD é favorável nos casos em que existe um modelo de domínio complexo (“... Ele se aplica sempre que estamos operando em um domínio complexo e intrincado” Eric Evans).

O que eu estou perdido é - como você define a complexidade de um domínio? Pode ser definido pelo número de raízes agregadas no modelo de domínio? A complexidade de um domínio está na interação de objetos?

O domínio que estamos avaliando está relacionado à publicação online e ao gerenciamento de conteúdo.

A complexidade da lógica de negócios, chamada de comportamento do aplicativo, é o fator mais importante. O segundo fator mais importante é a diferença entre o problema técnico e o vocabulário comercial usado para descrever esse problema, já que o DDD é sobre a criação de um vocabulário compartilhado entre o negócio e a equipe de engenharia.

Alguns dos padrões usados ​​no DDD são geralmente úteis na arquitetura de aplicativos corporativos, como o padrão de repositório, o contexto limitado e a arquitetura em camadas. Só porque você está usando esses padrões, não significa que você está criando um design orientado a domínio.

Se não houver muito comportamento, ou seja, você está armazenando dados em sua maioria e não agindo sobre esses dados, pode haver muito menos valor na criação dessa camada de domínio. No gerenciamento de conteúdo, se tudo o que você faz é aprovar e publicar, talvez isso possa ser representado por sinalizadores no sistema, em vez de métodos de domínio. Mas quando você começa a adicionar um comportamento adicional, a adequação de uma camada de domínio completa fica mais aparente.

Se estamos falando sobre gerenciamento de conteúdo, aqui estão algumas regras (imaginadas) que podem começar a sugerir a necessidade de DDD:

• Se a história for embargada até a data xx / aa / zz, publique para imprimir e depois na web; se não houver embargo, publique na web e disponibilize para impressão
• Disponibilize esta história por trás do paywall para assinantes pagos imediatamente; liberado ao público em geral duas semanas depois.
• Depois que uma história for escrita, envie-a a um editor para revisão, revisão e aprovação. Quando aprovado, envie-o para produção. Se a produção interromper a história por motivos de espaço, disponibilize uma versão estendida online.