O que é um domínio?


104

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?


12
Infelizmente, acho que é uma daquelas palavras que não tem uma definição clara e é usada em contextos ambíguos. Depois de ver o suficiente, você ganha um entendimento. O que quero dizer é que você não deve esperar entender seu uso, mesmo depois de ler todas as respostas que verá aqui. Isso levará tempo.
Aaaaaa

15
@aaaaaa exatamente ... Humpty Dumpty sorriu com desdém. ... "Quando uso uma palavra", disse Humpty Dumpty, num tom desdenhoso ", significa exatamente o que eu escolho - nem mais nem menos".
Emory 24/10

3
Eu não acho que seja verdade que não tenha uma definição clara. Se você olhar para a definição normal de webster, verá que é "uma região sobre a qual o domínio é exercido", "uma região marcada distintamente por algum recurso físico". Definição semelhante em matemática - o "domínio" de uma função. Você pode dividir algo grande em domínios ou regiões com base em quem é responsável por essa região ou com base em alguns critérios. Como um módulo. Portanto, um 'modelo de domínio' (no meu entendimento) é um modelo com o qual você pode trabalhar na lógica de negócios do seu aplicativo. DDD também tem a ver com tipos de "regiões".
Sava B.

Respostas:


9

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.


1
Re: seu último parágrafo: talvez devêssemos chegar a um acordo sobre o domínio principal do desenvolvimento de software? Mas, como concordar sobre o que é OOP, ou Funcional ou qualquer outro termo, acho que Humpty Dumpty venceu há muito tempo.

@nocomprende não, esses conceitos são específicos para um software individual específico em uma organização específica em um determinado momento. Assim, o domínio do núcleo para MSFT do Windows será diferente dependendo das condições de mercado, as expectativas do cliente, etc.
RibaldEddie

1
Eu acho que isso me lembra o velho ditado: "Existem 2 tipos de pessoas: aqueles que dividem as pessoas em dois tipos e aqueles que não o fazem". Mas ... para o segundo tipo de pessoas, haveria apenas um tipo de pessoas ... - erro de indireção infinita - sistema interrompido

@nocomprende desculpe, eu realmente não entendi seu primeiro comentário - a parte de “concordar” no domínio central do desenvolvimento de software era uma piada.
RibaldEddie

109

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


4
Sim. Quando você lê "domínio", pode substituir "(restrito a uma determinada) área de especialização ou preocupação".
KlaymenDK

1
O interessante é que o domínio do software realmente não tem nada a ver com o que os humanos estão tentando alcançar ou com o que eles entenderiam. Tenho certeza de que o computador simples do meu carro está fazendo coisas para otimizar a combustão de que nada sei e, francamente, não me importo. Portanto, supor que o software seja sobre a perspectiva e os desejos humanos é um mal-entendido muito perigoso. Isso pode ser útil, pois os sistemas de software abrangem áreas maiores, com maior conscientização e capacidade de escolher objetivos. Ei, espere, Asimov não pensou nisso, há tanto tempo?

1
@ user251748 - Bem, acho que é sobre humanos e os processos em que estão envolvidos, mas não necessariamente sobre o que as pessoas entendem instantaneamente.
Sipo

38

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.


7
Como os sites domain namestambém são conhecidos como domínios, acho que você deve esclarecer como está usando a palavra domínio aqui.
YetAnotherRandomUser

@YetAnotherRandomUser - Para mim, é bem claro o que ele quis dizer. ;)
Sipo

19

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.


7

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 .


Eu ajustaria sua definição das atividades do mundo real para o que o sistema de computadores está fazendo. Por exemplo, "O domínio de um sistema de controle de código-fonte é" - armazenamento e recuperação de arquivos de código-fonte . Os domínios são modelados, não para lidar com coisas do mundo real, mas para facilitar a construção e manutenção de sistemas de programação. Portanto, a ênfase está no que um computador pode fazer para facilitar isso, não no que os humanos podem fazer. Os raios X digitais melhoram a sensibilidade e o processamento de imagens do processo de raios X, não fazem nada para os seres humanos e seriam igualmente úteis para a digitalização automática de bagagem.

2

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 .


Eu diria que um domínio para software é o que o software faz. Certamente não existia antes de nós, e é inteiramente composto por nós, para fazer as coisas que queremos delegar para que elas aconteçam sem a nossa interação. Em outras palavras, é sobre um sonho que tivemos, que queremos esquecer. E esquecemos rapidamente como o software funciona assim que é implantado. O software é um jogo mais adequado para os computadores resolverem, só o fizemos até agora porque ainda não tínhamos construído os computadores, para resolver o problema pelo qual não queremos mais nos incomodar. Mas, muito em breve ...

Não me deixei claro nesta parte - "diante de nós", meu mal. Eu totalmente não quis dizer que o domínio existia antes da raça humana. Por "nós", eu quis dizer mais como desenvolvedores de software resolvendo um problema de automatização, digamos, de processos de negócios em comércio eletrônico. O conceito de comércio aparentemente existia antes deles. Portanto, a responsabilidade do desenvolvedor é permitir delegar coisas aos computadores, como você disse.

Direito. O que quero dizer é que as pessoas pensam que os sistemas de computador são uma maneira de lidar com o mundo real. Mas os computadores trazem muitas idéias, requisitos e preocupações que simplesmente nunca fizeram parte do domínio. É como dizer que a cirurgia é uma maneira de lidar com problemas emocionais. Bem, a lobotomia funciona, mas os problemas emocionais têm pouco a ver com o cérebro. E, meus sentimentos são fortemente afetados por hormônios e neurotransmissores, então os ISRSs fazem parte da biologia, da psicologia, dos relacionamentos ou são uma categoria para si? Computadores são sobre computadores, não coisas reais.

1
Computadores são sobre modelar coisas reais. Apenas outra área em que coisas reais poderiam ser feitas, processos de negócios reais poderiam ser implementados, restrições reais de negócios poderiam ser aplicadas. No entanto, meu dinheiro real foi retirado da minha conta bancária real. Portanto, não importa o que está envolvido em qualquer processo, computador ou humano ou outra coisa. Provavelmente, pode ser interessante para você: medium.com/@wrong.about/…

Dinheiro não é real. Os processos de negócios não são reais. Tudo o que podemos falar é um conceito, não real.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.