Modelos de domínio rico - como, exatamente, o comportamento se encaixa?

No debate dos modelos de domínio Rich vs. Anêmico, a Internet está cheia de conselhos filosóficos, mas com poucos exemplos de autoridade. O objetivo desta pergunta é encontrar diretrizes definitivas e exemplos concretos de modelos adequados de Design Orientado a Domínios. (Idealmente em c #.)

Para um exemplo do mundo real, essa implementação do DDD parece estar errada:

Os modelos de domínio WorkItem abaixo são nada além de pacotes de propriedades, usados ​​pelo Entity Framework para um banco de dados com código primeiro. Para Fowler, é anêmico .

A camada WorkItemService é aparentemente uma percepção errada comum dos Serviços de Domínio; Ele contém toda a lógica de comportamento / negócios do WorkItem. Por Yemelyanov e outros, é processual . (pág. 6)

Então, se o abaixo está errado, como posso fazer isso certo?
O comportamento, ou seja, AddStatusUpdate ou Checkout , deve pertencer à classe WorkItem correta?
Quais dependências o modelo WorkItem deve ter?

public class WorkItemService : IWorkItemService {
    private IUnitOfWorkFactory _unitOfWorkFactory;

    //using Unity for dependency injection
    public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) {
        _unitOfWorkFactory = unitOfWorkFactory;
    }

    public void AddStatusUpdate(int workItemId, int statusId) {

        using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) {
            var workItemRepo = unitOfWork.WorkItemRepository;
            var workItemStatusRepo = unitOfWork.WorkItemStatusRepository;

            var workItem = workItemRepo.Read(wi => wi.Id == workItemId).FirstOrDefault();
            if (workItem == null)
                throw new ArgumentException(string.Format(@"The provided WorkItem Id '{0}' is not recognized", workItemId), "workItemId");

            var status = workItemStatusRepo.Read(s => s.Id == statusId).FirstOrDefault();
            if (status == null)
                throw new ArgumentException(string.Format(@"The provided Status Id '{0}' is not recognized", statusId), "statusId");

            workItem.StatusHistory.Add(status);

            workItemRepo.Update(workItem);
            unitOfWork.Save();
        }
    }
}

(Este exemplo foi simplificado para ser mais legível. O código definitivamente ainda é complicado, porque é uma tentativa confusa, mas o comportamento do domínio era: atualizar status adicionando o novo status ao histórico do arquivo. Finalmente, concordo com as outras respostas, este pode ser tratado pelo CRUD.)

Atualizar

O @AlexeyZimarev deu a melhor resposta, um vídeo perfeito sobre o assunto em c # por Jimmy Bogard, mas aparentemente foi movido para um comentário abaixo porque não forneceu informações suficientes além do link. Eu tenho um rascunho das minhas anotações resumindo o vídeo na minha resposta abaixo. Por favor, sinta-se livre para comentar a resposta com quaisquer correções. O vídeo dura uma hora, mas vale a pena assistir.

Atualização - 2 anos depois

Eu acho que é um sinal da maturidade nascente do DDD que, mesmo depois de estudá-lo por 2 anos, ainda não posso prometer que sei o "caminho certo" de fazê-lo. Linguagem onipresente, raízes agregadas e sua abordagem ao design orientado por comportamento são as valiosas contribuições da DDD para a indústria. A ignorância da persistência e a fonte de eventos causam confusão, e acho que uma filosofia assim impede a adoção mais ampla. Mas se eu tivesse que repetir esse código novamente, com o que aprendi, acho que seria algo assim:

Ainda agradeço qualquer resposta a esta postagem (muito ativa) que forneça qualquer código de práticas recomendadas para um modelo de domínio válido.

A resposta mais útil foi dada por Alexey Zimarev e obteve pelo menos 7 votos positivos antes que um moderador o movesse para um comentário abaixo da minha pergunta original ....

Sua resposta:

Eu recomendo que você assista à sessão do NDC 2012 de Jimmy Bogard "Criando modelos de domínio maligno" no Vimeo. Ele explica o que um domínio rico deve ser e como implementá-lo na vida real, tendo comportamento em suas entidades. Exemplos são muito práticos e todos em C #.

http://vimeo.com/43598193

Fiz algumas anotações para resumir o vídeo, tanto para o benefício da minha equipe quanto para fornecer detalhes um pouco mais imediatos neste post. (O vídeo dura uma hora, mas vale a pena cada minuto, se você tiver tempo. Jimmy Bogard merece muito crédito por sua explicação.)

• "Para a maioria das aplicações ... não sabemos que elas serão complexas quando começarmos. Elas simplesmente se tornam assim."
  • A complexidade cresce naturalmente à medida que códigos e requisitos são adicionados. Os aplicativos podem começar muito simples, como CRUD, mas o comportamento / regras podem se tornar polêmicos.
  • "O bom é que não precisamos começar de forma complexa. Podemos começar com o modelo de domínio anêmico, que é apenas propriedade, e com apenas técnicas de refatoração padrão, podemos avançar em direção a um verdadeiro modelo de domínio".
• Modelos de domínio = objetos de negócios. Comportamento do domínio = regras de negócios.
• O comportamento geralmente está oculto em um aplicativo - pode estar em PageLoad, Button1_Click ou em classes auxiliares como 'FooManager' ou 'FooService'.
• As regras de negócios separadas dos objetos de domínio "exigem que lembremos" dessas regras.
  • No meu exemplo pessoal acima, uma regra de negócios é WorkItem.StatusHistory.Add (). Não estamos apenas mudando o status, estamos arquivando-o para auditoria.
• Comportamentos de domínio "eliminam erros em um aplicativo com muito mais facilidade do que apenas escrever vários testes". Os testes exigem que você saiba escrever esses testes. Os comportamentos do domínio oferecem os caminhos corretos para testar .
• Os serviços de domínio são "classes auxiliares para coordenar atividades entre diferentes entidades de modelo de domínio".
  • Serviços de domínio! = Comportamento do domínio. As entidades têm comportamento, os serviços de domínio são apenas intermediários entre as entidades.
• Objetos de domínio não devem possuir a infraestrutura de que precisam (por exemplo, IOfferCalculatorService). O serviço de infraestrutura deve ser passado para o modelo de domínio que o utiliza.
• Os modelos de domínio devem oferecer a você o que eles podem fazer e só devem poder fazer essas coisas.
• As propriedades dos modelos de domínio devem ser protegidas com setters privados, para que apenas o modelo possa definir suas próprias propriedades, através de seus próprios comportamentos . Caso contrário, é "promíscuo".
• Objetos de modelo de domínio anêmico, que são apenas pacotes de propriedades para um ORM, são apenas "uma camada fina - uma versão fortemente tipada no banco de dados".
  • "Por mais fácil que seja colocar uma linha do banco de dados em um objeto, é isso que temos".
  • A maioria dos modelos de objetos persistentes é exatamente isso. O que diferencia um modelo de domínio anêmico versus um aplicativo que realmente não tem comportamento é se um objeto possui regras de negócios, mas essas regras não são encontradas em um modelo de domínio. "
• "Para muitos aplicativos, não há necessidade real de construir qualquer tipo de camada lógica de aplicativos de negócios, é apenas algo que pode falar com o banco de dados e talvez uma maneira fácil de representar os dados que estão lá".
  • Portanto, em outras palavras, se tudo o que você está fazendo é CRUD sem objetos de negócios ou regras de comportamento especiais, você não precisa de DDD.

Por favor, sinta-se livre para comentar com outros pontos que você acha que devem ser incluídos, ou se você acha que alguma dessas notas está errada. Tentou citar diretamente ou parafrasear o máximo possível.

Sua pergunta não pode ser respondida, porque seu exemplo está errado. Especificamente, porque não há comportamento. Pelo menos não na área do seu domínio. O exemplo do AddStatusUpdatemétodo não é uma lógica de domínio, mas uma lógica que usa esse domínio. Esse tipo de lógica faz sentido estar dentro de algum tipo de serviço, que lida com solicitações externas.

Por exemplo, se havia um requisito de que um item de trabalho específico possa ter apenas status específico ou que possa ter apenas status N, isso é lógica de domínio e deve fazer parte de um WorkItemou de StatusHistoryum método.

O motivo da sua confusão é porque você está tentando aplicar uma diretriz ao código que não precisa dela. Os modelos de domínio são relevantes apenas se você tiver muita lógica de domínio complexa. Por exemplo. lógica que funciona nas próprias entidades e decorre dos requisitos. Se o código trata da manipulação de entidades a partir de dados externos, isso não é, muito provavelmente, uma lógica de domínio. Mas, no momento em que você obtém muitos ifs com base em quais dados e entidades você está trabalhando, isso é lógica de domínio.

Um dos problemas da modelagem de domínio verdadeiro é o gerenciamento de requisitos complexos. E, como tal, seu verdadeiro poder e benefícios não podem ser exibidos em código simples. Você precisa de dezenas de entidades com muitos requisitos ao seu redor para realmente ver os benefícios. Novamente, seu exemplo é muito simples para o modelo de domínio brilhar de verdade.

Finalmente, uma coisa do AT que eu mencionaria é que seria realmente difícil persistir um modelo de domínio verdadeiro com design de OOP real usando o Entity Framework. Embora os ORMs tenham sido projetados com o mapeamento da verdadeira estrutura de POO para as relacionais, ainda existem muitos problemas, e o modelo relacional geralmente vaza para o modelo de POO. Mesmo com o nHibernate, que considero muito mais poderoso que o EF, isso pode ser um problema.

Sua suposição de que encapsular sua lógica de negócios associada ao WorkItem em um "serviço fat" é um antipadrão inerente que eu argumentaria que não é necessariamente.

Independentemente de suas opiniões sobre o modelo de domínio anêmico, os padrões e práticas padrão típicos de um aplicativo Line of Business .NET incentivam uma abordagem em camadas transacional composta por vários componentes. Eles incentivam a separação da lógica de negócios do modelo de domínio especificamente para facilitar a comunicação de um modelo de domínio comum entre outros componentes .NET, bem como componentes em diferentes pilhas de tecnologia ou em camadas físicas.

Um exemplo disso seria um serviço Web SOAP baseado em .NET que se comunica com um aplicativo cliente Silverlight que possui uma DLL contendo tipos de dados simples. Esse projeto de entidade do domínio pode ser incorporado a um assembly .NET ou Silverlight, onde os componentes Silverlight interessados ​​que possuem essa DLL não serão expostos a comportamentos de objetos que podem depender de componentes disponíveis apenas para o serviço.

Independentemente da sua posição sobre esse debate, esse é o padrão adotado e aceito apresentado pela Microsoft e, na minha opinião profissional, não é uma abordagem errada, mas um modelo de objeto que define seu próprio comportamento também não é necessariamente um antipadrão. Se você avançar com esse design, é melhor perceber e entender algumas das limitações e pontos problemáticos que você pode enfrentar se precisar se integrar a outros componentes que precisam ver o seu modelo de domínio. Nesse caso específico, talvez você queira que um tradutor converta seu modelo de domínio de estilo orientado a objetos em objetos de dados simples que não exponham certos métodos de comportamento.

Sei que essa pergunta é bastante antiga, então essa resposta é para a posteridade. Quero responder com um exemplo concreto em vez de um baseado na teoria.

Encapsule a "alteração do status do item de trabalho" na WorkItemclasse da seguinte maneira:

public SomeStatusUpdateType Status { get; private set; }

public void ChangeStatus(SomeStatusUpdateType status)
{
    // Maybe we designed this badly at first ;-)
    Status = status;       
}

Agora sua WorkItemturma é responsável por se manter em um estado legal. A implementação é bem fraca, no entanto. O proprietário do produto deseja um histórico de todas as atualizações de status feitas no WorkItem.

Nós mudamos para algo assim:

private ICollection<SomeStatusUpdateType> StatusUpdates { get; private set; }
public SomeStatusUpdateType Status => StatusUpdates.OrderByDescending(s => s.CreatedOn).FirstOrDefault();

public void ChangeStatus(SomeStatusUpdateType status)
{
    // Better...
    StatusUpdates.Add(status);       
}

A implementação mudou drasticamente, mas o responsável pela chamada do ChangeStatusmétodo desconhece os detalhes subjacentes da implementação e não tem motivos para alterar a si próprio.

Este é um exemplo de uma entidade de modelo de domínio avançado, IMHO.