Separando responsabilidades no nível do domínio

https://medium.com/@diego_moura/domain-driven-design-contextos-delimitados-e-mapas-de-contextos-ded8e2574dff

Cada um no seu quadrado

Quando tratamos DDD, podemos fazer uma associação direta de um contexto delimitado ou bounded context, como sendo a representação tática de um departamento em uma empresa. Entenda como contexto delimitado, uma área especifica da empresa assim como marketing, financeiro, área de produtos, vendas, etc, que por sua vez, possuí responsabilidades específicas e consequentemente sua própria linguagem de ubíqua.

Um subdomínio é composto por pelo menos 1 contexto delimitado ou, o que significa que cada departamento da empresa será representado no modelo estratégico de domínio por um subdomínio, e este subdomínio terá uma representação análoga no modelo tático de domínio por um contexto delimitado.

Contextos delimitados servem para dar coerência à entidades que podem estar presentes em mais de 1 contexto delimitado, e consequentemente por estarem presentes em contextos distintos, essas entidades poderiam ter responsabilidades distintas e significados distintos por contexto.

Os contextos delimitados são formados a partir de subdomínios que por sua vez, possuem módulos (contêineres ou pastas para divisões lógicas afim de melhorar a separação entre as camadas e componentes do software) que encapsulam as responsabilidades em relação ao contexto o qual eles estão inseridos. Todavia, é comum termos pontos de intersecção entre dois ou mais contextos delimitados a partir de uma ou mais entidades, que podem existir em 2 ou mais contextos delimitados. No exemplo da imagem acima extraída do site de Martin Fowler, do post o qual ele trata sobre contextos delimitados, pode-se perceber que as entidades Product e Customer, estão presentes em ambos os contextos, sales context e support context. Do ponto de vista de domain-driven design a conceituação de cada termo pode assumir uma semântica diferente em cada contexto delimitado.

O relacionamento entre os contextos delimitados a partir das entidades, nos da a ideia de mapas de contextos ou context maps, uma representação visual do limite definido entre cada um dos contextos que se relacionam por alguma razão. O modelo de domínio e todos os seus componentes pressupostos (módulos, agregados, eventos, serviços, etc), as responsabilidades, casos de usos e regras de negócios da aplicação e do domínio, assim como a linguagem ubíqua, serão encapsulados dentro de cada contexto delimitado afim de manter a alta coesão e isolamento no nível do domínio, definindo assim um limite arquitetural entre todos os contextos disponíveis na aplicação.

Qual tamanho de um contexto delimitado? Um contexto delimitado deve ter o tamanho suficiente para ser capaz de abstrair e representar totalmente sua linguagem ubíqua e a esfera de conhecimento a qual ele representa. Cabe aqui o exercício de avaliar e refletir o modelo de domínio e sua respectiva linguagem ubíqua em relação ao contexto delimitado para remover tudo que exceder os limites do contexto em analise. Dessa forma você estará evitando de criar um super contexto que carregará mais do que o seu domínio básico necessita. Da mesma maneira, tome o devido cuidado para não remover conceitos e definições inerentes ao domínio com seus respectivos subdomínios os quais serão representados no contexto delimitado, garantindo que o contexto delimitado e esteja expressando por completo a linguagem ubíqua nele presente.

Conclusão

Contextos delimitados são partes essenciais da composição do universo tático de Domain Driven Design, e servem para compor o espaço de soluções que serão representados pelo software e seus componentes. Existe uma relação direta entre os modelos de domínios disponíveis no espaço dos problemas os quais são partes do modelo estratégico de Domain Driven Design, para os contextos delimitados no espaço de soluções, que como dito anteriormente, pertence ao modelo tático.

Através dos contextos delimitados, podemos organizar nosso software por esferas de conhecimento ou subdomínios, definindo limites arquiteturais que irão aumentar o isolamento e coesão dos domínios presentes na aplicação.

leitorEstaGostando() ? curtirEDarUmFeedback() : darUmFeedaback();

Valeuuuu! 🚗💨

Referência:

Implementando Domain-Driven Design

Implementando Domain-Driven Design apresenta uma abordagem completa para o entendimento de domaindriven design (DDD), a…

www.amazon.com.br