Design orientado por domínio

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

O design orientado por domínio ( DDD ) é uma abordagem de design de software [1] com foco na modelagem de software para corresponder a um domínio de acordo com a entrada dos especialistas desse domínio. [2]

Em termos de programação orientada a objetos , significa que a estrutura e a linguagem do código do software (nomes de classe, métodos de classe, variáveis ​​de classe ) devem corresponder ao domínio de negócios . Por exemplo, se um software processa pedidos de empréstimo, ele pode ter classes como LoanApplication e Customer e métodos como AcceptOffer e Withdraw.

O DDD conecta a implementação a um modelo em evolução. [3]

O design orientado ao domínio é baseado nos seguintes objetivos:

  • colocar o foco principal do projeto no domínio central e na lógica de domínio;
  • basear projetos complexos em um modelo do domínio;
  • iniciar uma colaboração criativa entre especialistas técnicos e de domínio para refinar iterativamente um modelo conceitual que aborda problemas de domínio específicos.

Críticas ao design orientado a domínio argumentam que os desenvolvedores normalmente devem implementar uma grande quantidade de isolamento e encapsulamento para manter o modelo como uma construção pura e útil. Embora o design orientado a domínio forneça benefícios como capacidade de manutenção, a Microsoft o recomenda apenas para domínios complexos em que o modelo oferece benefícios claros na formulação de um entendimento comum do domínio. [4]

O termo foi cunhado por Eric Evans em seu livro de mesmo título publicado em 2003. [5]

Visão geral [ editar ]

O design orientado a domínio articula vários conceitos e práticas de alto nível. [5]

De importância primordial é o domínio , a área de assunto à qual o usuário aplica um programa é o domínio do software. O domínio de um software governa seu contexto , a configuração na qual uma palavra ou declaração aparece que determina seu significado. A partir disso, os desenvolvedores constroem um modelo de domínio : um sistema de abstrações que descreve aspectos selecionados de um domínio e pode ser usado para resolver problemas relacionados a esse domínio.

Esses aspectos do design orientado a domínio visam promover a linguagem ubíqua, o que significa que o modelo de domínio deve formar uma linguagem comum compartilhada por especialistas de domínio para descrever os requisitos do sistema, usuários de negócios, patrocinadores e desenvolvedores.

No design orientado a domínio, a camada de domínio é uma das camadas comuns em uma arquitetura multicamada orientada a objetos .

Tipos de modelos [ editar ]

O design orientado a domínio reconhece vários tipos de modelos.

Por exemplo, uma entidade é um objeto definido não por seus atributos, mas por sua identidade . Por exemplo, a maioria das companhias aéreas atribui um número único aos assentos em cada voo: essa é a identidade do assento.

Em contraste, um objeto de valor é um objeto imutável que contém atributos, mas não tem identidade conceitual. Quando as pessoas trocam cartões de visita, por exemplo, elas se preocupam apenas com as informações do cartão (seus atributos), em vez de tentar distinguir entre cada cartão exclusivo.

Os modelos também podem definir eventos (algo que acontece). Um evento de domínio é um evento com o qual os especialistas de domínio se preocupam.

Os modelos podem ser vinculados por uma entidade raiz para se tornar um agregado . Objetos fora da agregação podem conter referências à raiz, mas não a qualquer outro objeto da agregação. A raiz agregada verifica a consistência das alterações na agregação. Os motoristas não precisam controlar individualmente cada roda de um carro, por exemplo: eles simplesmente dirigem o carro. Nesse contexto, um carro é um agregado de vários outros objetos (o motor, os freios, os faróis etc.)

Trabalhando com modelos [ editar ]

No design orientado a domínio, a criação de um objeto geralmente é separada do próprio objeto.

Um repositório , por exemplo, é um objeto com métodos para recuperar objetos de domínio de um armazenamento de dados (por exemplo, um banco de dados). Da mesma forma, uma fábrica é um objeto com métodos para criar diretamente objetos de domínio.

Quando parte da funcionalidade de um programa não pertence conceitualmente a nenhum objeto, normalmente ela é expressa como um serviço .

Relação com outras ideias [ editar ]

Embora o design orientado a domínio não esteja inerentemente vinculado a abordagens orientadas a objetos , na prática, ele explora as vantagens de tais técnicas. Isso inclui entidades/raízes agregadas como receptores de comandos/invocações de métodos, o encapsulamento de estado dentro das raízes agregadas mais importantes e, em um nível arquitetural mais alto, contextos limitados.

Como resultado, o design orientado a domínio é frequentemente associado a Plain Old Java Objects e Plain Old CLR Objects . Embora sejam detalhes técnicos de implementação, específicos para Java e .NET Framework , respectivamente, esses termos refletem uma visão crescente de que objetos de domínio devem ser definidos puramente pelo comportamento de negócios do domínio, em vez de uma estrutura de tecnologia mais específica.

Da mesma forma, o padrão de objetos nus sustenta que a interface do usuário pode ser simplesmente um reflexo de um modelo de domínio suficientemente bom. Exigir que a interface do usuário seja um reflexo direto do modelo de domínio forçará o projeto de um modelo de domínio melhor. [6]

O design orientado ao domínio influenciou outras abordagens de desenvolvimento de software.

A modelagem específica de domínio , por exemplo, é um design orientado a domínio aplicado com linguagens específicas de domínio . O design orientado a domínio não requer especificamente o uso de uma linguagem específica de domínio , embora possa ser usado para ajudar a definir uma linguagem específica de domínio e dar suporte a multimodelagem específica de domínio .

Por sua vez, a programação orientada a aspectos facilita a eliminação de preocupações técnicas (como segurança, gerenciamento de transações, log) de um modelo de domínio, permitindo que elas se concentrem apenas na lógica de negócios.

Engenharia e arquitetura orientadas a modelos [ editar ]

Embora o design orientado a domínio seja compatível com engenharia e arquitetura orientadas a modelos , [7] a intenção por trás dos dois conceitos é diferente. A arquitetura orientada a modelos está mais preocupada em traduzir um modelo em código para diferentes plataformas de tecnologia do que definir melhores modelos de domínio.

No entanto, as técnicas fornecidas pela engenharia orientada a modelos (para modelar domínios, criar linguagens específicas de domínio para facilitar a comunicação entre especialistas e desenvolvedores de domínio,...) modelos. Graças às técnicas de transformação de modelo e geração de código da engenharia orientada a modelos, o modelo de domínio pode ser usado para gerar o sistema de software real que irá gerenciá-lo. [8]

Segregação de responsabilidade de consulta de comando [ editar ]

Segregação de responsabilidade de consulta de comando (CQRS) é um padrão de arquitetura para separar dados de leitura (uma 'consulta') de gravação em dados (um 'comando'). CQRS deriva de Command and Query Separation (CQS), cunhado por Bertrand Meyer .

Os comandos mudam de estado e são aproximadamente equivalentes à invocação de método em raízes ou entidades agregadas. As consultas lêem o estado, mas não o alteram.

Embora o CQRS não exija um design orientado a domínio, ele torna explícita a distinção entre comandos e consultas com o conceito de uma raiz agregada. A ideia é que uma determinada raiz agregada tenha um método que corresponda a um comando e um manipulador de comandos invoque o método na raiz agregada.

A raiz agregada é responsável por executar a lógica da operação e gerar vários eventos, uma resposta de falha ou apenas alterar seu próprio estado que pode ser gravado em um armazenamento de dados. O manipulador de comandos extrai preocupações de infraestrutura relacionadas a salvar o estado da raiz agregada e criar contextos necessários (por exemplo, transações).

Fonte de eventos [ editar ]

O fornecimento de eventos é um padrão de arquitetura no qual as entidades não rastreiam seu estado interno por meio de serialização direta ou mapeamento relacional de objeto, mas lendo e confirmando eventos em um armazenamento de eventos .

Quando a origem de eventos é combinada com CQRS e design orientado a domínio, as raízes agregadas são responsáveis ​​por validar e aplicar comandos (geralmente fazendo com que seus métodos de instância sejam invocados de um manipulador de comandos) e, em seguida, publicar eventos. Essa também é a base sobre a qual as raízes agregadas baseiam sua lógica para lidar com invocações de métodos. Portanto, a entrada é um comando e a saída é um ou vários eventos que são salvos em um armazenamento de eventos e, em seguida, geralmente publicados em um agente de mensagens para os interessados ​​(como a visualização de um aplicativo ).

A modelagem de raízes agregadas para eventos de saída pode isolar o estado interno ainda mais do que ao projetar dados de leitura de entidades, como nas arquiteturas de passagem de dados padrão de n camadas. Um benefício significativo é que os provadores de teoremas axiomáticos (por exemplo, Microsoft Contracts e CHESS [9] ) são mais fáceis de aplicar, pois a raiz agregada oculta de maneira abrangente seu estado interno. Os eventos geralmente são persistidos com base na versão da instância raiz agregada, que gera um modelo de domínio que sincroniza em sistemas distribuídos por meio de simultaneidade otimista .

Ferramentas notáveis ​​[ editar ]

Embora o design orientado por domínio não dependa de nenhuma ferramenta ou estrutura específica, exemplos notáveis ​​incluem:

  • Actifsource , um plug-in para Eclipse que permite o desenvolvimento de software combinando DDD com engenharia orientada a modelos e geração de código .
  • CubicWeb , uma estrutura de web semântica de código aberto inteiramente orientada por um modelo de dados. As diretivas de alto nível permitem refinar o modelo de dados de forma iterativa, lançamento após lançamento. Definir o modelo de dados é suficiente para obter uma aplicação web funcional. É necessário mais trabalho para definir como os dados são exibidos quando as visualizações padrão não são suficientes.
  • OpenMDX , um framework MDA de código aberto baseado em Java que suporta Java SE , Java EE e .NET . O OpenMDX difere das estruturas MDA típicas em que "usa modelos para direcionar diretamente o comportamento de tempo de execução dos sistemas operacionais" .
  • Restful Objects , um padrão para mapear uma API Restful em um modelo de objeto de domínio (onde os objetos de domínio podem representar entidades, modelos de visualização ou serviços). Duas estruturas de código aberto (uma para Java e outra para .NET) podem criar uma API Restful Objects a partir de um modelo de domínio automaticamente, usando reflexão.

Veja também [ editar ]

Referências [ editar ]

  1. ^ Painço, Scott; Sintonia, Nick (2015). Padrões, Princípios e Práticas de Design Dirigido por Domínio . Indianápolis: Wrox. ISBN 978-1-118-71470-6.
  2. ^ Vernon, Vaughn (2013). Implementando Design Orientado a Domínio . Upper Sadle River, NJ: Addison-Wesley. pág. 3. ISBN 978-0-321-83457-7.
  3. ^ Design orientado por domínio.
  4. ^ Guia de arquitetura de aplicativos de Microsoft, 2ª edição. Recuperado de http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle .
  5. ^ a b Evans, Eric (2004). Design Orientado a Domínio: Lidando com a Complexidade no Coração do Software . Boston: Addison-Wesley. ISBN 978-032-112521-7. Recuperado 2012-08-12 .
  6. ^ Haywood, Dan (2009), Domain-Driven Design using Naked Objects , Pragmatic Programmers.
  7. ^ MDE pode ser considerado como um superconjunto de MDA
  8. ^ Cabot, Jordi (2017-09-11). "Comparando Design Orientado por Domínio com Engenharia Orientada por Modelo" . Linguagens de Modelagem . Recuperado 2021-08-05 .
  9. ^ uma ferramenta de localização de erros do MS

Links externos [ editar ]