This presentation discusses resource-oriented architecture and domain-driven design. It defines the core domain as the fundamental business concept behind the company and defines subdomains as either generic problems with established literature or supporting functions essential for the business. The presentation emphasizes understanding the domain to avoid architectural mistakes, enable alignment of goals between teams, and allow software to adapt quickly to changes. Defining domains and subdomains helps organize responsibilities and boundaries within complex software systems.
8. D O M Í N I O É S O B R E
C O M U N I C A Ç Ã O
9. – M . E . C O N WAY
“Organizations which design systems are
constrained to produce systems which are
copies of the communication structures of
these organizations.”
10. P R O B L E M A S D E C O M U N I C A Ç Ã O ,
D E S A L I N H A M E N T O S D E O B J E T I V O S E
C O N C E I T O S N Ã O S Ã O S A U D ÁV E I S
11. – M I C H A E L F E AT H E R S
“Misalignments between business
knowledge and development knowledge
persist in the code. We work around them
and, more often than not, end up building
on top of them rather than fixing them.”
12.
13. – B R I A N F O O T E A N D J O S E P H Y O D E R
“Domain experience is an essential
ingredient in any framework design
effort… Without knowing the architectural
demands of the domain, such an attempt
is premature, if not foolhardy…”
16. U M P R O B L E M A Q U E S E R Á
R E S O LV I D O U S A N D O U M S O F T WA R E
17. – VA U G H N V E R N O N
“When you develop software for an
organization, you’re working in its
Domain. It should be pretty obvious to
you what your Domain is. Your work in
it.”
23. 1. Por que escrever esse software vale a pena?
2. Por que não comprar uma solução pronta?
3. Por que não contratar alguém para construir esse software pra você?
24. É O C O N C E I T O F U N D A M E N TA L
P O R T R Á S D O N E G Ó C I O
25. – VA U G H N V E R N O N
“It’s a nontrivial problem to solve, and
succeeding would help the company
establish a new competitive advantage.”
26.
27. – E R I C E VA N S
“...the Core domain should deliver about
20% of the total value of the entire
system, be about 5% of the code base,
and take about 80% of the effort.”
30. PA R T E S D O S I S T E M A , Q U E A P E S A R D E S E R E M
E S S E N C I A I S PA R A O N E G Ó C I O , N Ã O FA Z E M
PA R T E D O C O R E D O M A I N
31. S E G U N D A D I V I S Ã O :
S U B D O M A I N S = G E N E R I C + S U P P O R T I N G
34. P R O B L E M A S Q U E P O S S U E M U M A L I T E R AT U R A
E X T E N S A , B E M E S TA B E L E C I D O S E E S TÁV E I S . N Ã O
N E C E S S A R I A M E N T E L I G A D O S A O N E G Ó C I O .
35. M Ó D U L O D E R E C O M E N D A Ç Ã O
D E P R O D U T O S
38. D I F E R E N T E D O S S U B D O M Í N I O S G E N É R I C O S , O S S U B D O M Í N I O S
D E S U P O R T E G A R A N T E M Q U E F U N C I O N A L I D A D E S E S S E N C I A I S
P R O N E G Ó C I O E S T E J A M D I S P O N Í V E I S .
39. M Ó D U L O D E PA G A M E N T O N U M
E - C O M M E R C E
40. R E G I S T R A N D O N O S S A
C O N Q U I S TA
44. U S E O D O M Í N I O C O M O P O N T E
PA R A S E C O M U N I C A R
45. C O N H E C E R S E U D O M Í N I O E V I TA E R R O S
A R Q U I T E T U R A I S G R AV E S N A C O N C E P Ç Ã O D O
S O F T WA R E
46. U M S O F T WA R E M E L H O R O R G A N I Z A D O E C O M
“ B A R R E I R A S ” E R E S P O N S A B I L I D A D E S B E M
D E F I N I D A S
47. P O S S I B I L I TA O A L I N H A M E N T O D E
O B J E T I V O S E N T R E A S Á R E A S D A E M P R E S A
48. U M S O F T WA R E B A S E A D O N U M D O M Í N I O
R E S P O N D E R Á P I D O A M U D A N Ç A S
49. – E R I C E VA N S
“...if programmers are not interested in the
domain, they learn only what the application
should do, not the principles behind it.
Useful software can be built that way, but the
project will never arrive at a point where
powerful new features unfold as corollaries
to older features.”
54. F O T O S
• https://flic.kr/p/r5VdWE - Green field
• https://flic.kr/p/pfiFkX - Bridging the gap
• https://flic.kr/p/5V6RA2 - Collaboration
• https://flic.kr/p/vqdF4d - Cornerstone
• https://flic.kr/p/ppsKuz - Library
• https://flic.kr/p/kbSRnu - Big ball of mud
55. R E F E R Ê N C I A S
•http://www.laputan.org/mud/
•http://www.jefclaes.be/2014/02/strategic-ddd-in-nutshell.html
•https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
•http://c2.com/cgi/wiki?ConwaysLaw
•http://www.r7krecon.com/#!provocation/gfqa5
•http://www.r7krecon.com/#!implications/t2tbw
•http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/
•http://blog.jonathanoliver.com/ddd-strategic-design-core-supporting-and-generic-subdomains
•Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans
•Implementing Domain-Driven Design - Vaughn Vernon