Qual a relação entre DDD e arquitetura de software? Até onde devemos ir com DDD?

1. Domain Driven Design
&
Software Architecture

2. • Uma arquitetura define ESTRUTURA.
• Uma arquitetura define COMPORTAMENTO.
• Uma arquitetura balanceia NECESSIDADES DOS STAKEHOLDERS.
• Uma arquitetura pode seguir um ESTILO ARQUITETURAL.
• Uma arquitetura é influenciada pelo AMBIENTE.
• Uma arquitetura influencia a estrutura do TIME.
• TODO SOFTWARE TEM UMA ARQUITETURA.
• Decisões na arquitetura influenciam em custo, manutenibilidade,
performance, escalabilidade, etc.
Reflitamos sobre arquitetura de software

3. • Inclui todas as atividades que auxiliam na transformação da
especificação de requisitos na implementação. Os principais artefatos
do processo de design de software incluem:
• Especificação de Requisitos
• Design de Alto Nível
• Design Detalhado
Reflitamos sobre design de software

4. Arquitetura vs Design

5. • Camadas
• Microserviços
• Pipes and Filters
• Plugins
• Client/server
• Etc
Estilos Arquiteturais

6. • MVC
• CQRS
• Event Sourcing
• 3 camadas
• Onion
• Clean
• Hexagonal
• Etc...
Padrões Arquiteturais

7. E a arquitetura DDD?

8. NÃO EXISTE ARQUITETURA DDD!!!

9. Não mesmo? Mas todo mundo usa? Vi no
LinkedIn!

10. O que é DDD afinal?

11. 14
2003

12. DDD – Domain Driven Design
• DDD não é sobre arquitetura, é
sobre design, é sobre como você
aborda o negócio para criação do
software!
• Indicado para aplicações
complexas com muitas entidades
e regras de negócio.
• “Simples” de entender, muito
difícil de aplicar.

13. • DDD é sobre negócio:
• Agrupar conhecimentos de negócio.
• Reconhecer e separar subdomínios.
• Desenhar modelo de domínio rico.
• DDD pode ser usado com qualquer estilo ou padrão arquitetural:
CQRS, estrutura em camadas, etc.
• DDD é uma abordagem de design (modelagem) de software, não é
tecnologia e poderia ser chamado de “filosofia”.
DDD – Domain Driven Design

16. Mas, e as camadas DDD? E os padrões DDD?

17. Precisamos de tudo isso?

18. Arquitetura em Camadas: Onion Architecture
• Batizada por Jeffrey Palermo.
• Dependência de fora para
dentro.
• "This architecture is not
appropriate for small
websites." (Palermo, J.)

19. Arquitetura em Camadas: Onion Architecture
• "I propose a new approach to
architecture. Honestly, it’s not
completely new, but I’m
proposing it as a named,
architectural pattern. Patterns are
useful because it gives software
professionals a common
vocabulary with which to
communicate. There are a lot of
aspects to the Onion Architecture,
and if we have a common term to
describe this approach, we can
communicate more
effectively." (Palermo, J.)

20. Arquitetura em Camadas: Onion Architecture
• "Hexagonal architecture and
Onion Architecture share the
following
premise: Externalize
infrastructure and write
adapter code so that the
infrastructure does not
become tightly coupled."
(Palermo, J.)
https://jeffreypalermo.com/2008/07
/the-onion-architecture-part-1/

21. Arquitetura em Camadas: Hexagonal Architecture
• Batizada por Alistair
Cockburn.
• Também conhecida como
"Ports and Adapters".

22. Arquitetura em Camadas: Clean Architecture
• Batizada por Robert
C. Martin – Uncle
Bob.
https://8thlight.com/blog/u
ncle-bob/2012/08/13/the-
clean-architecture.html

23. E por que não simplificar?
API API
API
O mais importante é a IoC e o baixo acoplamento do bloco de Business e não as camadas em si!
(Faraday, Gabriel)

24. • “Nos lugares onde os aspectos arquiteturais são levadas a sério como
imprescindíveis para o sucesso de qualquer projeto é cada vez mais
consenso de que a maneira tradicional de arquitetar sistemas não
está provendo todo o valor que deveria.” (Giovanni Bassi)
• Problemas do modelo tradicional:
• Código inútil
• Over-engineering
• Código embaraçoso
• Complexidade de manutenção
• Não tenha medo do refactoring!
Arquitetura Emergente

25. Arquitetura Emergente vs Agile Manifesto
http://agilemanifesto.org/iso/ptbr/manifesto.html

26. Arquitetura Emergente vs Agile Principles
• Mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento.
• Software funcionando é a medida primária de progresso.
• Simplicidade--a arte de maximizar a quantidade de trabalho não
realizado--é essencial.
• As melhores arquiteturas, requisitos e designs emergem de equipes
auto organizáveis.
• Contínua atenção à excelência técnica e bom design aumenta a
agilidade.
http://agilemanifesto.org/iso/ptbr/principles.html

27. Obrigado!