Quem nunca ouviu falar a celebre frase: Meu gerente e a empresa onde eu trabalho não dão importância se estamos aplicando o padrão XYZ. Para a empresa, o que importa é ter o produto no mercado trazendo monetização para a instituição. Essa afirmação tem sua parcela de verdade. A mudança na forma de pensar não tem que partir de fora para dentro e nem de dentro para fora, o que tem que existir é o entendimento do valor curto, médio e longo prazo que essas práticas vão trazer ao projeto. O time precisa voltar seus olhares também para o seu dia a dia. Pense em algo que é divertido, escalável, fácil de manter, tem legibilidade e é fácilmente testado. Pensou? Vamos apresentar caminhos que utilizam Agilidade aplicada ao DDD+BDD+TDD para não aplicarmos mais uma Arquitetura: BOLOVO ou CEBOLA

1. Globalcode
– Open4education
Arquitetura .NET
PENSE FORA DA CAIXA: APLIQUE AGILIDADE COM DOMAIN DRIVEN
DESIGN. VOCÊ AINDA USA ARQUITETURA BOLOVO?
JOSÉ ROBERTO ARAÚJO YAN JUSTINO
Bacharel em Análise de Sistemas
MCP
Bacharel em Análise de Sistemas
MCP | MCST | MSP

2. Globalcode
– Open4education
AGENDA
O QUE É DOMAIN-­DRIVEN DESIGN?
DESTILANDO O PROBLEMA DO DOMÍNIO
FOCO NO CORE DOMAIN

3. Globalcode
– Open4education
QUAISOSDESAFIOSde"CRIAR"UMSOFTWARE
PARADOMiNIOSCOMPLEXO?

4. Globalcode
– Open4education
LINGUAGEM COMUM

5. Globalcode
– Open4education

6. Globalcode
– Open4education
DDD É SOBRE A
REDUÇÃO DE
COMPLEXIDADE
NO SOFTWARE
Eric Evans
ARQUITETURA É
SOBRE INTENÇÃO
Robert C. Martin

7. Globalcode
– Open4education
A FALTA DE
ORGANIZAÇÃO

8. Globalcode
– Open4education
BOLA DE LAMA
PATTERN

9. Globalcode
– Open4education
BELEZA, ISSO TUDO EU SEI!!!
COMO É QUE EU RESOLVO ESSA BAGAÇA!!!

10. Globalcode
– Open4education

11. Globalcode
– Open4education
COMO DDD GERENCIA
COMPLEXIDADES
DESTILANDO o problema de domínio para revelar o que realmente
importa
Criando MODELO para resolver problemas de domínio
Usando uma LINGUAGEM COMPARTILHADA para habilitar
modelagem colaborativa
ISOLANDO modelos de ambiguidade e corrupção
Entendendo a RELAÇÃO ENTRE CONTEXTOS

12. Globalcode
– Open4education
"Modelos menores proporcionam muitos benefícios, permitindo definir limites claros
relativos às responsabilidades de concepção e desenvolvimento de equipes.
[Quando] um contexto tem uma superfície menor, você tem menos efeitos colaterais"
Julie
Lerman is
a
Microsoft
MVP,
.NET
mentor
and
consultant
who
lives
in
the
hills
of
Vermont.
You
can
find
her
presenting
on
data
access
and
other.NET
topics
at
user
groups
and
conferences
around
the
world.
She
blogs
at thedatafarm.com/blog and
is
the
author
of
“Programming
Entity
Framework”
(2010),
as
well
as
a
Code
First
edition
(2011)
and
a
DbContext
edition
(2012),
all
from
O’Reilly
Media.
Follow
her
on
Twitter
attwitter.com/julielerman and
see
her
Pluralsight
courses
at juliel.me/PS-
Videos.

13. Globalcode
– Open4education
STRATEGIC PATTERNS OF
DOMAIN DRIVEN DESIGN

14. Globalcode
– Open4education
SUPERFÍCIE DO
PROBLEMA

15. Globalcode
– Open4education
DESTILANDO O PROBLEMA
DO DOMÍNIO
“MASTIGANDO” O CONHECIMENTO
Colaboração
MÉTODOS PARA IMERSÃO NO CONHECIMENTO DO DOMÍNIO
Conversas focadas no mais importante
Business Model Canvas
Perguntas poderosamente relevantes
Lista de casos de uso
Esboço
CRC (Class Responsibility Collaboration Cards)
Adiar a nomeação de conceitos em seu modelo
BDD
Prototipagem Rápida

16. Globalcode
– Open4education
SUPERFÍCIE DA
SOLUÇÃO

17. Globalcode
– Open4education
BOUNDED CONTEXT

18. Globalcode
– Open4education
DIFERENÇA ENTRE MODELO DE
NEGÓCIO E MODELO DE DOMÍNIO

19. Globalcode
– Open4education

20. Globalcode
– Open4education
MANIFESTAÇÃO DO BOLO
DE LAMA

21. Globalcode
– Open4education

22. Globalcode
– Open4education
E SE…

23. Globalcode
– Open4education
E SE…

24. Globalcode
– Open4education
ENTÃO…

25. Globalcode
– Open4education
E DIGO MAIS…

26. Globalcode
– Open4education
ARQUITETURA

27. Globalcode
– Open4education

28. Globalcode
– Open4education
REFERÊNCIAS
http://www.infoq.com/presentations/ddd-­imperfect-­design
https://skillsmatter.com/skillscasts/6259-­ddd-­and-­microservices-­at-­last-­
some-­bounderies
Domain-­Driven Design
(Eric Evans)
Patterns, Principles and Practices of Domain-­Driven Design
(Millett and Tune)
Implementing Domain-­Driven Design
(Vaughn Vernon)