Uma abordagem para modelagem de software que reúne conceitos, princípios e técnicas para resolver problemas de negócio.
- Domínio
- Design estratégico
- Linguagem onipresente
- Modelos
- Bounded Context
Uma esfera de conhecimento e/ou atividades.
É uma forma de representar alguma área do negócio da empresa.
Tipos:
- Core
- Supporting
- Generic
- É a parte mais importante do DDD
- Extrair conhecimentos
É um catálogo de padrões de projeto que nos ajuda a criar códigos que sejam o reflexo do nosso modelo de negócio
- Linguagem versátil compartilhada pela equipe
- Unifica a divisão linguística entre os envolvidos tornando-a em uma linguagem comum
- No cenário atual time de negócio tem um conhecimento limitado do jargão técnico
- São conjunto de itens que descrevem a funcionalidade do sistema
- Descrevem aspectos do domínio assim como é utilizado para resolver um determinado problema
- O modelo reflete a visão do domínio
Modelagem, classificação e diagramas inter relacionados.
- Desbravando as fronteiras do seu negócio
- Delimita o seu domínio complexo em contextos baseados nas intenções do negócio
- Estimula a criação de squads por contexto
Um contexto compartilhado entre outros contextos, o shared kernel é um tipo de contexto onde N bounded contexts dependem dele, uma espécie de Core, este tipo de contexto não pode ser alterado sem consultar todos os times de desenvolvimento que dependem dele.
Exemplo
Contextos customer dependem de contextos supplier.
A equipe downstream atua como cliente (customer) da equipe upstream (supplier). As equipes definem testes de aceitação automatizados que validam as interfaces que a equipe upstream fornecem. A equipe upstream pode então fazer alterações em seu código sem medo de quebrar alguma coisa da equipe downstream.
É o cenário onde as equipes downstream e upstream não estão mutuamente alinhadas e a equipe downstream precisa atender o negócio com o que a equipe upstream fornece mesmo não estando de acordo com as necessidades. A equipe downstream precisa aceitar este fato, se conformar com isto.
Neste cenário duas equipes possuem dependências mútuas em seus contextos e precisam somar esforços de modelagem para se atenderem mutuamente.
Neste cenário a equipe downstream desenvolve uma camada adicional anti-corrupção para se comunicar com o contexto upstream, é o cenário típico onde o supplier é um sistema legado ou uma API mal desenvolvida.
Exemplo
Uma camada a parte que não obedece a hierarquia de camada. Como o próprio nome diz, essa camada cruza toda a hierarquia. Contém as funcionalidades que pode ser utilizada em qualquer parte do código, como, por exemplo, validação de CPF/CNPJ, consumo de API externa e utilização de alguma segurança.
Exemplo