DDD, modularizando as camadas de aplicativo e domínio sem quebrar o DIP

Ele não divide o DIP porque o Domínio é o nível mais alto, maior que o Aplicativo, e não depende dele. O inverso (Domínio dependendo do aplicativo) quebraria o DIP.

[Editar: esclarecimento] Além disso, a parte "depende da abstração" do DIP não se aplica necessariamente aqui, porque as entidades de domínio não podem ser abstraídas - elas já são um modelo conceitual puro de seu domínio. A única exceção pode ser os Serviços de Domínio, porque você poderia colocar uma interface na frente deles.

Como observação, você geralmente não precisa aproveitar a inversão de dependência dentro do próprio modelo de domínio, porque

• As entidades de domínio têm poucos ou nenhum colaborador
• Os que eles têm são bem identificados (linguagem onipresente) e muitas vezes não têm natureza polimórfica
• O domínio reside inteiramente na memória, sem comunicação externa (estrutura de terceiros, rede, disco, etc.) envolvida, para que possa ser testado com testes de integração rápida sem precisar de falsificações.

O Princípio de Inversão de Dependência tem uma grande exceção: em algum momento você deve fazer algo concreto. Um exemplo está em ordem.

Digamos que você tenha um aplicativo de blog. Você tem duas tabelas no banco de dados e dois modelos de domínio, digamos Blog e Post . Digamos também que você está trabalhando com uma estrutura MVC como ASP.NET MVC, Ruby on Rails, etc.

Agora, digamos que você tenha outra classe chamada BlogPostsController implementando as operações básicas do CRUD para postagens de blog.

O framework implementa o Princípio de Inversão de Dependência ao não codificar permanentemente as seguintes linhas em qualquer lugar em sua base de código:

new BlogPostsController();

A estrutura examina a URL recebida e constrói o nome da classe do controlador dinamicamente. O framework não tem uma dependência difícil da sua classe BlogPostsController .

Agora, vamos ver o controlador. Dentro do seu controle, você vê new Post() recheados. Isso não é uma violação do Princípio de Inversão de Dependência porque em algum momento você, como programador, precisa salvar uma postagem de blog no banco de dados.

O Princípio de Inversão de Dependência é principalmente voltado para dependências que não são focadas em laser na intenção básica de uma classe, por exemplo, criando um novo "controlador" em uma estrutura MVC. Você não deseja uma instrução switch ou if codificada para fazer isso. Autenticação é outra área em que o DIP é importante porque sua classe BlogPostsController não deve se importar como os cookies do navegador são manipulados ou se o usuário efetua login usando uma página de login customizada conectada a um Banco de Dados ou usando autenticação do Windows ou texto simples no navegador conectado ao LDAP nos bastidores.

O DI significa que sua camada de Aplicação não deve depender diretamente das classes de Serviço de Domínio, mas de interfaces abstratas dessas classes de serviço (na verdade, seu diagrama já está mostrando isso). A única coisa que é discutível é se essas interfaces devem ser colocadas na camada de domínio. É melhor colocá-los fora, em uma camada "Service Interface", para que eles possam ser referenciados na camada Application e na camada Domain. Dessa forma, você não tem dependências diretas entre a camada de aplicativo e a camada de domínio, em nenhuma das duas direções possíveis.

Naturalmente, como Greg já apontou, em algum lugar do seu aplicativo você precisa conectar tudo e criar instâncias não-abstratas de suas classes de serviço de domínio. Ou você usa uma estrutura de DI para esse propósito, ou faz isso manualmente em uma espécie de parte de "infraestrutura" do seu programa, fora de qualquer uma das "camadas" clássicas. Nem uma estrutura de DI, nem uma infraestrutura de start-up manual é relevante no sentido do DIP.