A palavra "domínio" no livro Design dirigido por domínio de Eric Evans tem um significado específico. É sobre o assunto do software.

Evans vai mais longe embora. Em sua opinião, existem sub-domínios, mesmo com o mesmo software. E esta é a parte do livro que trata do “Design Estratégico”.

Existem três "domínios": o domínio principal, o domínio de suporte e o domínio genérico. Às vezes, ele se referirá a eles como subdomínios.

Evans também se preocupa profundamente com os negócios reais por trás do software e o livro não é direcionado apenas aos desenvolvedores, mas também aos arquitetos e gerentes que precisam ver como o software e a empresa podem trabalhar juntos, e é nisso que ele se preocupa. discutindo o design estratégico e esses sub-domínios.

Assim, o domínio central é a parte do software que representa tanto a vantagem competitiva quanto a "razão de ser" do software. É a parte do software que é o motivo pelo qual um cliente compraria o software em vez de outro software. Normalmente, Evans o vê como o domínio que contém a menor porcentagem de código. Você pode pensar nisso como os 20% mais importantes. É a parte que você realmente não pode comprar na prateleira e pode ser apenas um único módulo ou componente do software geral.

O domínio de suporte ainda é importante e pode ser exclusivo da organização, mas não é tão importante quanto o domínio principal. Sem isso, o software não será tão valioso e o núcleo depende dele. Pode ser vários módulos no software que você mesmo escreveu e que executam funções importantes, mas de suporte, ao núcleo.

O domínio genérico é o menos personalizado e, em algum sentido, a parte menos importante do software. Você pode ter escrito isso em casa, mas pode ser mais eficiente apenas comprá-lo na prateleira ou usar um software de código aberto bem conhecido. Esta parte do sistema provavelmente não é específica para o seu domínio geral, portanto, por exemplo, se você tem um sistema de envio que roteia pacotes ou um sistema de registros de saúde que gerencia pacientes, o domínio genérico é a parte desses sistemas que são comuns e justos simplesmente precisa estar lá para funcionar. Isso provavelmente compõe a maior parte do sistema, mas não necessariamente.

De uma perspectiva de negócios, é importante decidir qual é o seu domínio principal e concentrar seus recursos de desenvolvimento nele. Evans tem muitos vídeos, particularmente no site da InfoQ, onde explica esses conceitos com mais detalhes.

Por isso, embora muitas vezes falemos sobre "o domínio" no software, no caso do DDD, não é tão simples quanto parece.

Devo observar que os conceitos de DDD não existem necessariamente na comunidade de software mais ampla. Outros desenvolvedores, autores e pessoas de produtos podem ter ideias e definições diferentes, algumas mais sutis e outras menos. Mesmo outros autores que escreveram sobre o DDD podem encobrir esses conceitos no livro de Evans, mas eu sinto que os conceitos ainda são úteis ao escrever e planejar um projeto de software.

O domínio é o contexto do mundo real no qual você está tentando resolver um problema usando software. Cada domínio vem com conhecimentos, vocabulário e ferramentas que fazem parte desse domínio.

Um exemplo específico de um domínio poderia ser algo como "a usinagem automatizada de peças complexas usando um cortador giratório de alta velocidade". O sistema de software e hardware que faz isso é chamado de CNC mill .

Outro exemplo de domínio é o departamento de contabilidade de uma corporação.

Leitura adicional em Contexto limitado de Martin Fowler

Significa simplesmente o espaço do problema em que você está trabalhando. Por exemplo, se você estivesse criando um site de comércio eletrônico, seu domínio seria "comércio eletrônico" e envolveria os processos associados às práticas de vendas do cliente / empresa. Assim, um modelo de domínio seria algo para representar um produto ou uma fatura ou um registro de envio.

Um Domínio é uma área de conhecimento. Pode ser uma atividade na qual existem problemas resolvidos pelo seu software. ( Wiki , Comunidade DDD )

Eric Evans, em seu livro, usa o transporte de carga para explicar o que é DDD. Em seu exemplo, domínio é tudo sobre envio . Como a carga é movida, gerenciada, enviada e rastreada, etc. Ele vem com suas próprias regras específicas, linguagem e processos. Eles criarão modelos de domínio, objetos, serviços e assim por diante.

Quando você cria um aplicativo, você tem algum tipo de autorização, assim como o mundo real do envio, nem todos podem acessar os armazéns. Como os usuários são autorizados e como as permissões são concedidas podem estar fora do domínio , porque a informação pode não ser relevante para o envio de carga.

Simplificando: um domínio é onde você faz negócios . Se o seu negócio é transporte de carga, a carga de envio será o seu domínio. Se a sua empresa está em autenticar e autorizar pessoal, este será o seu domínio.

De Design orientado a domínio: Enfrentando a complexidade no coração do software , Eric Evans:

Every software program relates to some activity or interest of its user. That subject area to which the user applies the program is the domain of the software.

The domain of an airline-booking program involves real people getting on real aircraft.

The domain of an accounting program is money and finance.

The domain of a source-code control system is software development itself.

O modelo de domínio, então, é "uma abstração rigorosamente organizada e seletiva de" o conhecimento na cabeça de um especialista em domínio.

Palermo, ao descrever a arquitetura da cebola, ofereceu este resumo

In the very center we see the Domain Model, which represents the state and behavior combination that models truth for the organization.

Fowler, por sua vez, oferece

An object model of the domain that incorporates both behavior and data.

Se você está procurando definições mais recentes, é mais provável que você encontre referências que modelo de domínio e o modelo de dados são diferentes . Eu não considero isso uma mudança de significado tanto quanto uma mudança de ênfase - modelar os comportamentos (a forma como os dados mudam em resposta a informações de fora do modelo) tem complexidade e variação mais ricas do que as diferentes maneiras de escrever as coisas .

Como você provavelmente já tem uma ideia do que é domínio, acho que a próxima etapa a ser tomada é tentar definir o subdomínio, o modelo de domínio e, mais importante, o contexto limitado.

Eu começo colocando minha perspectiva de domínio.

Domínio

Domínio é a realidade que habitamos: suas entidades, seu comportamento, leis que eles obedecem. Existiu antes de nós e existirá depois de nós, de uma forma ou de outra. Sua existência não depende da nossa consciência. Os profissionais de marketing criam novos recursos e realizam análises de mercado, os principais gerentes de contas se comunicam com os clientes, os desenvolvedores de software automatizam os processos de negócios. É por isso que o domínio é chamado de espaço para problemas.

Subdomínios

O DDD implica a decomposição do domínio em subdomínios, para facilitar sua modelagem e compreensão. O próprio fato de você executar um negócio infere que há pelo menos um valor comercial predominante. Aquele com quem você ganha dinheiro. Aquele para o qual começamos nosso negócio. Portanto, mesmo que você não conheça uma palavra como “domínio central”, ela ainda está presente. O mesmo se aplica aos subdomínios: provavelmente você precisará de uma contabilidade, recursos humanos, suporte técnico - mas é secundário.

Modelo de domínio

Não há necessidade de modelar subdomínios na sua totalidade. Há um certo conjunto de regras em cada subdomínio em que estamos interessados. Um conjunto de regras em algum subdomínio que é necessário para alcançar um determinado resultado comercial é chamado de modelo.

Contextos limitados

O mais importante é que o contexto limitado é um limite lógico.

Quando os subdomínios e o domínio principal são definidos, é hora de implementar o código. Contexto limitado define limites tangíveis de aplicabilidade de algum subdomínio. É uma área em que um determinado subdomínio faz sentido, enquanto os outros não. Pode ser uma palestra, uma apresentação, um projeto de código com limites físicos definidos pelo artefato.

O que vem a seguir?

Se você estiver interessado em como o conceito de contexto limitado se correlaciona com o conceito de subdomínio, como definir subdomínios e contextos delimitados, como representar a comunicação entre eles e como organizar equipes com esses conceitos em mente, provavelmente você seria interessado neste outras leituras .