Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Alexey Zimarev
Software Architect at ABAX AS, Norway
DDD Norway Meetup Organiser
@Zimareff
alex@zimarev.com
https://www.li...
Domain-Driven Design
Why, What and How
History of Programming
FORTRAN
1957
Science
Math
Engineering
LISP
1958
Lots of parenthesis
LISP
1958
Math
AI
Lambda calculus
COBOL
Common Business-
Oriented
Language
1959
Business
Finance
Administration
ALGOL
1958
Computer science
Found no adoption
Early days programmers
Mathematicians
Scientists
Engineers
Business people
COBOL was almost like plain English
Computer people took the
language with least adoption
among domain experts
and started using it everywhere
Cobol only evolved to
another Cobol
Business
Still does programming
Waterfall
Collect requirements
Design
Code
Test
Maintain
Book on
Requirement
s
Customer
Gone missing
Domain-
Driven
Design
2003
Eric Evans
The Blue Book
Knowledge crunching
Ubiquitous language
Model-driven design
Implementation patterns (entity, aggregate, aggr...
What went wrong?
Strategy is hard
Tactics is easier
People prefer easier
tasks
Layered Architecture
Domain
Model
Starts simple and
clean
Domain
Model
Growth a little
Domain
Model
A little more
Domain
Model
Eventually…
Big Ball of Mud
“A Big Ball of Mud is a haphazardly structured,
sprawling, sloppy, duct-tape-and-baling-wire,
spaghetti-code jungle. These...
Big Ball of Mud
Most popular
architecture style
Does something useful
Without telling anyone
how
Hard to impossible to
cha...
It started so well!
Look, I have entities
Wow, here is my
aggregate root
Check this, I got bunch
of repositories
“DDD Light”
Look, I have entities
Wow, here is my
aggregate root
Check this, I got bunch
of repositories
That is not DDD
developing
Ubiquitous Language
within
Bounded Context
Context is the thing
The bandage was wound
around the wound.
We must polish the Polish.
He could lead if he would get the
...
We are linguists
Talk to domain experts
Whiteboard
Event Storming
Observations
Business Model Canvas
BDD/Visual Language (Given-When-Then)
Bounded Context
The place where language lives
Same word might have different meaning in another
context
High cohesion - h...
Layers - per context
Context Map
Core Domain
Core Domain
Competitive advantage
Absolutely critical part
Distinction from
competitors
Problem space
complexity
Core Domain
Best resources
Strong focus
Good design
Supportive subdomain
Candidate for off-the-shelf software
Prefer buying versus building
Candidate for CRUD
Can be outsourc...
Single model
Wobbly
Too big - hard to reason
about
Tightly coupled
Hard to test
Requires coordination
Coordination
Reality is different
Contextual models
Focused
Small - easier to reason
about
Decoupled
Easy to change
Enables autonomy
Autonomy
Bounded context creates autonomy
Allows teams working in parallel
Little or no coordination
Independent release a...
–Eric Evans
“DRY is inside the bounded context,
NOT the whole system.”
DO NOT
Don’t concentrate on technicalities
Don’t expect the ideal model, expect many iterations
Don’t over-engineer
Protec...
–Eric Evans
“Good design is imperfect design.”
DO
Speak to domain experts (using their language)
Crunch knowledge
Find core domain
Refactor towards deeper insight
–Alberto Brandolini
“Software development is a learning process.
Working software is a side effect”
Reading
DDD - What, why, how?
DDD - What, why, how?
DDD - What, why, how?
DDD - What, why, how?
DDD - What, why, how?
DDD - What, why, how?
DDD - What, why, how?
Upcoming SlideShare
Loading in …5
×

DDD - What, why, how?

2,499 views

Published on

Many people who start exploring Domain-Driven Design (DDD) are wondering what it's all about. Some argue that all those implementation pattern are important. Others say that these patterns should have been excluded from the Blue Book in sake of strategic design. I mostly agree with the latter and explain why in this presentation. It was presented at the first DDD Norway meetup in Oslo, on the 1st of March 2017.

Published in: Software
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

DDD - What, why, how?

  1. 1. Alexey Zimarev Software Architect at ABAX AS, Norway DDD Norway Meetup Organiser @Zimareff alex@zimarev.com https://www.linkedin.com/in/alexeyzimarev http://zimarev.com
  2. 2. Domain-Driven Design Why, What and How
  3. 3. History of Programming
  4. 4. FORTRAN 1957 Science Math Engineering
  5. 5. LISP 1958 Lots of parenthesis
  6. 6. LISP 1958 Math AI Lambda calculus
  7. 7. COBOL Common Business- Oriented Language 1959 Business Finance Administration
  8. 8. ALGOL 1958 Computer science Found no adoption
  9. 9. Early days programmers Mathematicians Scientists Engineers Business people
  10. 10. COBOL was almost like plain English
  11. 11. Computer people took the language with least adoption among domain experts and started using it everywhere
  12. 12. Cobol only evolved to another Cobol
  13. 13. Business Still does programming
  14. 14. Waterfall Collect requirements Design Code Test Maintain
  15. 15. Book on Requirement s
  16. 16. Customer Gone missing
  17. 17. Domain- Driven Design 2003 Eric Evans
  18. 18. The Blue Book Knowledge crunching Ubiquitous language Model-driven design Implementation patterns (entity, aggregate, aggregate root, value object, strategy, domain service, domain event, repository, etc) Supple design, Refactoring towards deeper insight Strategic design (bounded context, context map, core domain, subdomains)
  19. 19. What went wrong? Strategy is hard Tactics is easier People prefer easier tasks
  20. 20. Layered Architecture
  21. 21. Domain Model Starts simple and clean
  22. 22. Domain Model Growth a little
  23. 23. Domain Model A little more
  24. 24. Domain Model Eventually…
  25. 25. Big Ball of Mud
  26. 26. “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition” –Brian Foote and Joseph Yoder's - Big Ball of Mud - 1997
  27. 27. Big Ball of Mud Most popular architecture style Does something useful Without telling anyone how Hard to impossible to change
  28. 28. It started so well! Look, I have entities Wow, here is my aggregate root Check this, I got bunch of repositories
  29. 29. “DDD Light” Look, I have entities Wow, here is my aggregate root Check this, I got bunch of repositories That is not DDD
  30. 30. developing Ubiquitous Language within Bounded Context
  31. 31. Context is the thing The bandage was wound around the wound. We must polish the Polish. He could lead if he would get the lead. The soldier decided to desert his dessert in the desert. Since there is no time like the present, he thought it was time to present the present. http://www.mtmlinguasoft.com/context-is-everything-especially-in-translation/
  32. 32. We are linguists
  33. 33. Talk to domain experts Whiteboard Event Storming Observations Business Model Canvas BDD/Visual Language (Given-When-Then)
  34. 34. Bounded Context The place where language lives Same word might have different meaning in another context High cohesion - hard to split Speed of change - things change together
  35. 35. Layers - per context
  36. 36. Context Map
  37. 37. Core Domain
  38. 38. Core Domain Competitive advantage Absolutely critical part Distinction from competitors Problem space complexity
  39. 39. Core Domain Best resources Strong focus Good design
  40. 40. Supportive subdomain Candidate for off-the-shelf software Prefer buying versus building Candidate for CRUD Can be outsourced
  41. 41. Single model Wobbly Too big - hard to reason about Tightly coupled Hard to test Requires coordination
  42. 42. Coordination
  43. 43. Reality is different
  44. 44. Contextual models Focused Small - easier to reason about Decoupled Easy to change Enables autonomy
  45. 45. Autonomy Bounded context creates autonomy Allows teams working in parallel Little or no coordination Independent release and feedback cycle
  46. 46. –Eric Evans “DRY is inside the bounded context, NOT the whole system.”
  47. 47. DO NOT Don’t concentrate on technicalities Don’t expect the ideal model, expect many iterations Don’t over-engineer Protect context boundaries, don’t allow shortcuts and leaking abstractions from other contexts Respect and don’t ubiquitous language
  48. 48. –Eric Evans “Good design is imperfect design.”
  49. 49. DO Speak to domain experts (using their language) Crunch knowledge Find core domain Refactor towards deeper insight
  50. 50. –Alberto Brandolini “Software development is a learning process. Working software is a side effect”
  51. 51. Reading

×