Bom... continuando a série de recortes de trechos de trabalhos acadêmicos que fiz no passado sobre DDD (Domain-Driven Design)... aqui vai a parte 2 contendo trechos do capítulo 4 de meus resumos sobre DDD.

>

4. Padrões Estratégicos do DDD

O DDD possui técnicas específicas para realizar a avaliação de um problema num dado domínio (problem space assessment) e obter um modelo conceitual do domínio que ajude a projetar uma solução de acordo com o(s) contexto(s) delimitado(s) descoberto(s) e suas possíveis integrações (solution space assessment) (Vernon, 2013).

Neste capítulo, pretende-se explorar os conceitos e elementos envolvidos para aplicar estas técnicas que juntas são conhecidas como modelagem estratégica, porém com mais ênfase no problem space assessment. Isto é, serão tratados os conceitos sobre Domínio, Subdomínios e Contextos Delimitados, além de reforçar a importância do uso da Linguagem Ubíqua.

4.1 Domínio e Subdomínios

De modo geral, o domínio compreende as atividades que uma Empresa realiza no âmbito das relações de negócios, as quais ocorrem em um determinado segmento ou nicho de mercado do mundo real (Vernon, 2013). Em termos de software, entende-se que o mesmo auxilia a Empresa a cumprir seus objetivos por meio de sistemas computacionais que permitam controlar os processos e as informações nas diversas áreas de negócio que a compõe, agregando valor ao negócio (Vernon, 2013).

Porém, como a palavra Domínio pode se referir aos processos e atividades da Empresa como um todo ou apenas de uma área principal ou de suporte, no DDD, convém empregar as noções de Domínio Principal e Subdomínios, Genéricos e de Suporte (Vernon, 2013).

O Domínio Principal corresponde aos processos e atividades de negócio de uma área da Empresa que é responsável por entregar os principais produtos ou serviços da empresa; enquanto Subdomínios de Suporte capturam importantes aspectos do negócio que são essenciais e que contribuem para a execução das atividades do Domínio Principal, sendo de certa forma, especializados em um determinado assunto (Vernon, 2013). Por fim, os Subdomínios Genéricos não estão ligados aos conceitos de negócio da Empresa mas são necessários para a solução de software como um todo (Vernon, 2013).

O conjunto formado pelo Domínio Principal e Subdomínios caracterizam o espaço do problema. A análise dos Subdomínios já existentes e dos futuros Subdomínios que serão necessários ajudam a descobrir rapidamente quais partes do Domínio resolvem um problema específico (Vernon, 2013).

Deste modo, o DDD enfatiza a necessidade de se decompor o Domínio em vários Subdomínios para que se possa diminuir a complexidade de implementação de um software e obter uma separação de responsabilidades mais natural, tendo em vista que cada função do negócio será tratada separadamente (Vernon, 2013), possivelmente modularizados (Meyer, 1988 apud Pressman, 2001 p. 373).

4.2 Linguagem Ubíqua

Segundo Vernon (2013), a Linguagem Ubíqua é uma construção linguística que captura os termos utilizados no Ambiente de Negócio no qual o Projeto está sendo desenvolvido e serve como expressão máxima do Modelo de Domínio (Domain Model) e códigos construídos pela Equipe de Desenvolvimento em conjunto com os Especialistas de Negócio no contexto do software que está sendo desenvolvido. Por causa desta característica, a Linguagem Ubíqua deve ser a linguagem em comum utilizada por todos da equipe.

Referências

Vernon, 2013: Vernon, Vaughn , Implementing Domain-Driven Design, 2013

Meyer, 1988 apud Pressman, 2001 p. 373: Meyer, B.; Pressman, Roger S, Object-Oriented Software Construction; Software engineering: a practitioner’s approach, 2001