8. Goal of this talk
■ Understand big picture of DDD
■ Be able to identify the current situation of business
■ Know the best approach given the current situation
■ Inspire and encourage the vision of bringing business
value through code
@carolkarklis
18. What is NOT
■ Business language (jargons, terms, etc)
Photo by Hans-Peter Gauster on Unsplash
19. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
Photo by Hans-Peter Gauster on Unsplash
20. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
■ A way of naming things in the code
Photo by Hans-Peter Gauster on Unsplash
21. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
■ A way of naming things in the code
■ The way developers communicate about the system
Photo by Hans-Peter Gauster on Unsplash
22. What is NOT
■ Business language (jargons, terms, etc)
■ Communication of domains experts
■ A way of naming things in the code
■ The way developers communicate about the system
■ Communication about how the system should work
(speculative)
Photo by Hans-Peter Gauster on Unsplash
23. "The practice of building up a
common, rigorous language
between developers and users"
Eric Evans
24. Ubiquitous language
It is based on domain model and express how the system works in an
understandable way for everyone in the team
A language about a shared knowledge of domain
made by the team
35. Investments takes
time
The definition of investment is to apply resource, time and
effort in exchange of something later. You must consider if the
team is willing to invest in building better software.
42. statement
The system is completely guided by data and you can classify
it as a CRUD solution (create, read, update, delete). Your
team only needs a pretty interface for data manipulation.
scenario #1
43. statement
The system is completely guided by data and you can classify
it as a CRUD solution (create, read, update, delete). Your
team only needs a pretty interface for data manipulation.
scenario #1
diagnosis
You don't need to invest time and effort from your team to
practice DDD. That doesn't mean you should not worry
about code quality.
44. statement
The system requires only 30 or less business operations, is
probably very simple to have a overview of the system. This
means that your application don't have more than 30 use
cases (methods), and each one of them have minimal business
rules. Because of that, you don't feel lack of control by
business complexity. This is a common scenario for startups
doing their MVP.
scenario #2
45. statement
The system requires only 30 or less business operations, is
probably very simple to have a overview of the system. This
means that your application don't have more than 30 use
cases (methods), and each one of them have minimal business
rules. Because of that, you don't feel lack of control by
business complexity. This is a common scenario for startups
doing their MVP.
scenario #2
diagnosis
You could even have a challenge in your mind right now, but
practicing DDD is a high cost because you didn't feel the pain
of complexity yet. Maybe is the moment to gather domain
experts and evolve the ubiquitous language.
46. What you can do
■ Evolve ubiquitous language
■ Use a tool that analyzes the code (rubocop, code
climate, source level, etc)
■ Make an organized mess
■ Analyze software metrics like Churn vs Complexity
55. Churn
It is a measure of how often a file changes. Files
that change more have bigger churn.
56. Complexity
Usually is calculated by Cyclomatic Complexity,
which calculates the quantity of independent
paths your code have (control transferences,
logical sequences, etc)
72. "What's the future cost of doing
nothing now?"
Sandi Metz, from talk "Go ahead, make a mess"
73. statement
Let's say that you moved from 30 to 40 features and your
starting to question complexity of things that need to be
done. The system may not be maintained by an unique team,
but by multidisciplinary teams. You are thoughtful about
product evolution inside each team, and questioning if is
possible to keep a stable system with code quality and
reliable architecture.
scenario #3
74. statement
Let's say that you moved from 30 to 40 features and your
starting to question complexity of things that need to be
done. The system may not be maintained by an unique team,
but by multidisciplinary teams. You are thoughtful about
product evolution inside each team, and questioning if is
possible to keep a stable system with code quality and
reliable architecture.
scenario #3
diagnosis
You are coming close to the point where there is a real
benefit in making code design: The benefit of productivity
and being happy. Your team should start talking about code
design (including DDD)
75. What you can do
■ If possible, distribute senior people across the teams, ensuring that
the team have at least one person with experience in designing code
(and failing)
■ Make periodical checks to talk about code quality and architecture
(with team leaders). Like a code therapy.
■ Make fishbowls/meetups with product managers and developers to
talk about it and analyze opportunities.
■ Start DDD with Strategic Modeling, never Tactical Patterns
76. Start practicing DDD with
Strategic Modeling
Don't start with tactical patterns. For real.
80. Defining bounded contexts
It's a component so important as ubiquitous language when practicing DDD
Is how DDD deals with models of big subdomains:
Separating they by business intentions.
84. exercise
■ Make a list of every subdomain you remember in your
routine
■ Make a list of bounded contexts
■ Use a template to understand how bounded contexts
communicate between them.
■ Do it and redo it as many times as necessary
85. statement
Too many people and features to be managed. Requirements
change and this requires lot of effort from the team in
thinking about how to maintain current code and still make
the necessary changes without breaking the system.
scenario #4
86. statement
Muitas pessoas e features para serem administradas. Os
requisitos mudam e isso requer muito esforço do time em
pensar como manter o código atual e ainda fazer as
mudanças necessárias sem que outras coisas quebrem no
sistema.
scenario #4
87. statement
Too many people and features to be managed. Requirements
change and this requires lot of effort from the team in
thinking about how to maintain current code and still make
the necessary changes without breaking the system.
scenario #4
diagnosis
The time has come and you should invest in code design and
practice DDD as much as possible. It's time to plan system
changes.
88. statement
Too many people and features to be managed. Requirements
change and this requires lot of effort from the team in
thinking about how to maintain current code and still make
the necessary changes without breaking the system.
scenario #4
diagnosis
Chegou o momento esperado de investir em design de código
e praticar DDD o quanto for possível. É hora de planejar
mudanças no seu sistema.
89. What you can do
■ Collect all the effort from Strategic Modeling to use tactical
patterns
■ Make a plan and focus on execution
96. Tactical Patterns
They are also more practical than Strategic Modeling. It is worth mentioning that
these patterns are applied within a bounded context.
Resources closer to the code
97. A few patterns
■ Value Objects
■ Entities
■ Domain Services
■ Repositories
■ Aggregates
A verdade é que nós desenvolvedores somos péssimos pra identificar quando algo começa a ficar complexo
Nesse ponto tudo muda. Se o time não conseguir pegar tempo pra fazer um bom design,a performance começa a cair porque o sistema vai ficando mais engessado e difícil de modificar. Com um bom design, a performance fica mais constante e é possível ter mais entregas do que um sistema com nenhum ou péssimo design
Não precisa ser algo formal e nem muito organizado. Você pode pegar um fluxo e pedir para o especialista explicar. Por exemplo: Como funciona o fluxo de resgate?
É ISSO que você quer extrair da conversa: conceitos e palavras em comum. É assim que você testa se a linguagem do seu código reflete a realidade, e é assim que você constrói a linguagem ubíqua
Depois dessa conversa, documente ela no papel. Como esse fluxo funciona? O que é importante de ser dito sobre ele?
A ideia não é manter uma documentação 100% fiel ao código o tempo todo, mas sim extrair os conhecimentos da reunião pra algo mais duradouro
Depois de documentar o fluxo, envie para os especialistas e outros desenvolvedores. Esse é um ótimo exercício
Falar do rubocop e source level
Falar do rubocop e source level
Falar do rubocop e source level
Fazer fishbowls com o time de dev pra discutir sobre qualidade de código e espalhar conhecimento em design
Se possível, fazer com que cada time tenha pelo menos uma pessoa com experiência em design de código
Fazer checks periódicos
Aproveite a oportunidade de lançar uma feature para fazer ela do zero, e não refatorar algo que vc já tem dificuldade de usar
Não deixe a discussão sobre produto longe de refactor/design de código. Quanto mais perto, quanto mais vc mostrar a preocupação para os PM's, mais fácil
Tentar encaixar o Shapeup aqui
DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
Vamos pensar nesse domínio: Ele tem intenções e contextos diferentes.
O que um usuário significa em cada um desses subdomínios?
Por exemplo, o termo CLIENTE pode ter vários significados
Quando o usuario tá na vitrine, é uma coisa
Quando faz o pedido, outra
No pedido é bem limitado, o CLIENTE representa pouca coisa: eu só quero saber o tipo de pagamento e um endereço de entrega dele
Agora vamos falar de intenções
QUal a intenção de tudo isso? Vender um produto?
Quase tudo é sobre vender um produto
A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra
Mas eu diria que a intenção do ESTOQUE é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo.
São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
Its almost certain that terms and meanings collide in the domain. For example, the term customer must have multiple meanings. When a user is browsing the catalog, customer means one thing. When placing an order, it means something else. Here's why: WHen browsing catalog, customer is being used in the context of previous purchase, loyalty, product availability, discounts. On the order, however, customer has a limited meaning. Customer means very little comparing to catalog: it's payment terms, ship-to address
Nesse exemplo mais simples, a gente poderia dizer que a intenção de quase tudo que tá sendo exposto aí é vender um produto. Ponto.
A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra
Mas eu diria que a intenção do estoque é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo.
São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
Its almost certain that terms and meanings collide in the domain. For example, the term customer must have multiple meanings. When a user is browsing the catalog, customer means one thing. When placing an order, it means something else. Here's why: WHen browsing catalog, customer is being used in the context of previous purchase, loyalty, product availability, discounts. On the order, however, customer has a limited meaning. Customer means very little comparing to catalog: it's payment terms, ship-to address
Nesse exemplo mais simples, a gente poderia dizer que a intenção de quase tudo que tá sendo exposto aí é vender um produto. Ponto.
A vitrine existe porque ela quer que você compre. A experiência que voce tem com pedido e entrega pode fazer você comprar mais. Contabilidade é consequencia da compra
Mas eu diria que a intenção do estoque é diferenciada de todas as outras. A intenção de negócio pra existencia do estoque é ter visibilidade do que se tem disponível a venda. A quantidade das coisas pra serem vendidas. Isso pode ajudar a definir o que entra numa promoção, por exemplo.
São intenções diferentes. Então, nesse exemplo, eu vou separar o estoque dos outros, como bounded contexts diferentes.
is a set of technical resources used in the construction of your Domain Model, these resources must be applied to work in a single Bounded Context.
