Eu vejo muito esse termo no contexto da arquitetura de software ("modelo de domínio", "design orientado a domínio" etc.). Eu pesquisei no Google, mas recebi toneladas de definições diferentes. Então, o que é realmente?

A palavra "domínio" no livro Domain Driven Design, de Eric Evans, tem um significado específico. É disso que trata o software.

Evans vai mais longe. Na sua opinião, existem subdomínios mesmo com o mesmo software. E essa é a parte do livro que lida com “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 refere 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 é apenas voltado para desenvolvedores, mas também para arquitetos e gerentes que precisam ver como o software e os negócios podem trabalhar juntos, e é com isso que ele se preocupa ao discutir o design estratégico e esses subdomínios.

Portanto, o domínio principal é a parte do software que representa a vantagem competitiva e a "razão de ser" do software. É a parte do software que explica por que um cliente compraria o software versus 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 da prateleira e pode ser apenas um único módulo ou componente do software em 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 ele, o software não será tão valioso e o núcleo depende disso. Pode haver vários módulos no software que você escreveu e que executam funções importantes, mas de suporte ao núcleo.

O domínio genérico é o menos personalizado e, em certo sentido, a parte menos importante do software. Você pode ter escrito internamente, mas pode ser mais eficiente comprá-lo imediatamente ou usar um software de código aberto bem conhecido. Essa parte do sistema provavelmente não é específica para o seu domínio geral. Por exemplo, se você tem um sistema de remessa que encaminha parcelas ou um sistema de registros de saúde que gerencia pacientes, o domínio genérico é a parte desses sistemas que é comum e justa. simplesmente precisa estar lá para funcionar. Provavelmente, isso compõe a maior parte do sistema em geral, mas não necessariamente.

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

Portanto, embora falemos frequentemente 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 do produto podem ter idéias e definições diferentes, algumas mais sutis e outras menos. Até outros autores que escreveram sobre DDD podem encobrir esses conceitos no livro de Evans, mas acho que os conceitos ainda são úteis ao escrever e planejar um projeto de software.

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

Um exemplo específico de um domínio pode ser algo como "a usinagem automatizada de peças complexas usando um cortador rotativo de alta velocidade". O sistema de software e hardware que realiza isso é chamado de usina CNC .

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

Leitura adicional
Contexto limitado por Martin Fowler

Significa simplesmente o espaço problemático 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 seu cliente / empresa. Portanto, um modelo de domínio seria algo para representar um produto, uma fatura ou um registro de remessa.

Um domínio é uma área do 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 cargas para explicar o que é DDD. No seu exemplo, domínio é tudo sobre remessa . Como a carga é movimentada, gerenciada, embarcada e rastreada, etc. Ela vem com regras, idioma e processos específicos e próprios. Eles criarão modelos de domínio, objetos, serviços e assim por diante.

Ao criar um aplicativo, você terá algum tipo de autorização, assim como o mundo real da remessa, 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 as informações podem não ser relevantes para o transporte de carga.

Simplificando: um domínio é onde você faz negócios . Se sua empresa estiver enviando carga, ela será o seu domínio. Se sua empresa estiver autenticando e autorizando pessoal, esse será o seu domínio.

Do Design Orientado a Domínio: Lidando com a Complexidade no Coração do Software , Eric Evans:

Todo programa de software está relacionado a alguma atividade ou interesse de seu usuário. A área de assunto à qual o usuário aplica o programa é o domínio do software.

O domínio de um programa de reserva de companhias aéreas envolve pessoas reais embarcando em aeronaves reais.

O domínio de um programa de contabilidade é dinheiro e finanças.

O domínio de um sistema de controle de código-fonte é o próprio desenvolvimento de software.

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

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

No centro, vemos o Modelo de Domínio, que representa a combinação de estado e comportamento que modela a verdade para a organização.

Fowler, por sua vez, oferece

Um modelo de objeto do domínio que incorpora comportamento e dados.

Se você estiver procurando definições mais recentes, é mais provável que encontre referências de que o modelo de domínio e o modelo de dados são diferentes . Não considero que uma mudança de significado seja apenas uma mudança de ênfase - modelar os comportamentos (a maneira como os dados mudam em resposta às 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 idéia do que é domínio, acho que o próximo passo será tentar definir subdomínio, modelo de domínio e, mais importante, contexto limitado.

No entanto, eu começo colocando minha perspectiva de domínio.

Domínio

Domínio é a realidade em que habitamos: suas entidades, seu comportamento, leis a que obedecem. Existia 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 de Problema.

Subdomínios

DDD implica decomposição de domínio em subdomínios, para facilitar sua modelagem e compreensão. O próprio fato de você administrar uma empresa infere que há pelo menos um valor comercial predominante. Aquele com quem você ganha dinheiro. Para quem iniciamos nosso negócio. Portanto, mesmo se você não souber uma palavra como "Domínio principal", ela ainda estará presente. O mesmo se aplica aos subdomínios: provavelmente você precisará de contabilidade, recursos humanos, suporte técnico - mas é secundário.

Modelo de domínio

Não há necessidade de modelar subdomínios extraídos na sua totalidade. Existe um certo conjunto de regras em cada subdomínio no qual estamos interessados. Um conjunto de regras em algum subdomínio 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. O contexto limitado define limites tangíveis de aplicabilidade de algum subdomínio. É uma área em que um certo 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.

Qual é o próximo?

Se você estiver interessado em saber como o conceito de contexto delimitado se correlaciona com o conceito de subdomínio, como definir subdomínios e contextos delimitados, como representar sua comunicação um com o outro e como organizar equipes com esses conceitos em mente, provavelmente você estaria interessado nisso leitura adicional .