How relevant is domain-driven design (DDD) 13 years after Eric Evans' well-known blue book? The book and the community it grew out of was to a large extent defined by how large enterprises built their IT systems at the start of this century, dominated by the two large and all-encompassing platforms J2EE and .NET, often constructed in a very planned and controlled way. How on earth could this then be relevant in a world dominated by agility, microservices, and a plethora of technologies and platforms? Actually, central DDD concepts like bounded context, core domain, ubiquitous language, distillation, and aggregates fits even better in such a dynamic world than the large monoliths we struggled with back then. This rich toolbox contains techniques that helps us getting more intimate with the business, better understanding their visions and needs; principles helping us designing better and more sustainable solutions that are closely linked with the domain; and pattens for constructing autonomous components in an agile fashion. Fits like a glove! Presentation held at JavaZone 2016.

1. Making IT your winning asset

2. Trond Hjorteland
Partner at scienta.no
@trondhjort

3. Microservices without DDD is
risky business!

4. @trondhjort

5. Imposter syndrome
Source: David Whittaker @rundavidrun
What I think others know
What I
know
What I
know
What others know
@trondhjort

6. @trondhjort

8. “This _____ discusses modularisation as a
mechanism for improving the flexibility and
comprehensibility of a system while allowing the
shortening of its development time.”
@trondhjort
-David Parnas, 1972
paper

9. Source: D.L. Parnas, Communications of the ACM, 1972

11. Source: “From Capabilities to Services…”, Ulrich Homann & Jon Tobey 2006@trondhjort

13. Customer
Account
Subscription
@trondhjort

14. Source: http://bill-poole.blogspot.com, 2008@trondhjort

15. @trondhjort

16. Service-orientation
Boundaries are explicit
Services are autonomous
Services share schema and contract, not class
Service compatibility is based on policy
s
@trondhjort

18. @trondhjort

19. "DDD, for me, is a mindset, a journey, a way of
‘learning’ more about a business domain and its
problem, not a destination or an artefact in
some code base.”
@trondhjort

20. Collaboration of software and domain experts
Focus on the core domain
Ubiquitous language in a bounded context
The essence of DDD
@trondhjort Source: Domain-Driven Design Reference

21. Strategic patterns
Source: Domain-Driven Design Reference@trondhjort

22. Source: Patterns, Principles and Practices of Domain-Driven Design@trondhjort

23. Source: Ulrich Kalex, The Open Group@trondhjort

24. Subdomains
Customer
Account
Subscription
Billing Customer Care
Subscription
Management
Billing
Account
Customer
Subscription
Portfolio
Owner Payer
Sales Invoice
Install base
Products
@trondhjort

25. “All models are wrong
but some are useful”
-George Box
Source: Robustness in Statistics, 1978@trondhjort

26. Source: Implementing Domain-Driven Design@trondhjort

27. @trondhjort

28. Tactical patterns
Source: Domain-Driven Design Reference@trondhjort

29. Aggregate Subscription
Portfolio
Owner
Portfolio
Subscription
A
customerId
Subscription
B
Subscription
C
Subscription
B
?@trondhjort

30. Subdomain ⊇ Service (BC) ⊇ Aggregate
Subscription
Portfolio
Owner
Portfolio
management
⊇
Taxonomy
Portfolio
Subscription A Subscription B Subscription C
⊇
@trondhjort

31. Delivery approaches
Top-down
Bottom-up
Architecture principles
Inverse Conway Manoeuvre
@trondhjort

32. Source:(http://geek/and/poke.com/(
Source: http://geek-and-poke.com/@trondhjort

33. @trondhjort

35. @trondhjort Source: https://dddeurope.com