Lidar com um modelo de domínio anémico

Question

Eu estava tentando separar o meu DAL da minha camada de negócios, e ao fazê-lo, decidi evitar qualquer abordagem ActiveRecord e ir para uma abordagem DataMapper. Em outras palavras, meus objetos de domínio não iria cuidar de persistir a si mesmos. Ao fazê-lo, eu parecem estar invadindo o "anêmica modelo de domínio" anti-padrão. Por exemplo, uma das entidades no meu programa é uma Organização.

Uma organização é representada como algo parecido com isto:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

Então, basicamente, esta organização não faz nada diferente de agir como "bag" (como Martin Fowler diz) para alguns dados. No mundo do PHP não é nada mais do que uma matriz glorificado. Não é um comportamento de zero a ela associados.

E o comportamento no programa, eu tenho que adere em "nível de serviço" class como um OrganizationService que serve principalmente como um intermediário entre esses objetos e o DAL.

Além de potenciais problemas de escala com PHP (eu tenho outras razões pelas quais eu insisto em "ensacamento" meus dados nesses objetos), é esta abordagem totalmente fora?

Como você lida com seus modelos de domínio nessas situações? Talvez uma organização não faz parte do meu domínio, em primeiro lugar?

Answer 1

Bem, parece que isso no início, mas quando você refatorar seu código mais, você vai chegar a algum comportamento para sua classe organização ...

Um exemplo que eu poderia pensar agora é se você tem as pessoas (funcionários), você pode querer associá-los a organização. assim, você pode ter um AssociateEmployee(User employee) método que pode encontrar o seu lugar em sua classe organização.

Ou você pode alterar a localização da empresa, em vez de definir parâmetros como endereço, cidade, estado em três passos, você pode adicionar o método de ChangeLocation(Street, City, State) ..

Basta ir passo a passo, quando se deparar com algum código em que você camada BL / serviço que parece que deve pertencer ao domínio, movê-lo para baixo para o domínio. Se você ler Fowler, você vai buscá-la muito em breve quando você vê-lo em seu código.

Answer 2

Pode ser apenas anêmico agora?

Por exemplo, uma vez vez que eu estava desenvolvendo um site de registro de conferência / reunião. Tudo começou com apenas uma reunião.

Ainda havia uma classe reunião e apenas um exemplo, mas no ano seguinte, realizamos a conferência, foi ampliado e novas propriedades foram adicionadas (para segurar duas reuniões back-to-back), tão claramente a apenas não foi totalmente ainda desenvolvido, como nós, em seguida, adicionou grupos de reuniões que pode conter várias reuniões.

Então, eu acho que é importante ter em mente que os domínios mudar ao longo do tempo e seu modelo pode acabar sendo reformulado, por isso mesmo que você pode pensar que é anêmica, que poderia ser apenas um pouco demasiado prospectivas (como sua classe organização vai começar a receber algumas definições, regras ou preferências ou algo assim).

Answer 3

Você também pode considerar que, se você não tem um monte de regras de negócio, ou o domínio não é tão complexo, que DDD pode ser muita sobrecarga para você. DDD é uma excelente solução para grandes domínios, complicado, mas é um monte de sobrecarga ea complexidade se você está simplesmente fazendo dados, dados para fora. DDD é mais difícil de projetar e inerentemente aumenta a complexidade, de modo a justificar, a complexidade do domínio do problema devem compensar isso.

Isso é tudo o que eu gostaria de acrescentar a zappan e epitka.

Answer 4

A sua entidade não está anêmico porque você está tomando um reposnsibility que não deveria estar lá, para começar. Persistindo e buscar entidades é reponsibility de repositórios. Realmente o seu comportamento deve estar em suas entidades não em uma camada de serviço. Mas explicando o que vai para onde é muito além do simples resposta. DDD por Eric Evans é um ponto de partida bom.