DDD - A Java perspective

Complex, data-intensive applications present significant and challenging development issues. Domain-Driven Design (DDD) is one approach to discovering and addressing these challenges, helping you build your domain model in the 'right' way.

The new Jakarta Data specifications introduce an entirely new, type-safe programming model for persistence in Java. This model follows a Domain-Centric Approach, in contrast to the Entity-Centric model familiar from the Java Persistence API.

In this session, we will explore how to leverage the core concepts of DDD—such as Aggregates, Bounded Contexts, and an Anti-Corruption Layer—to define, design, and build effective software. And your teammates will thank you for it!

Transcript

1. FREDERIEKE SCHEPER 1 DDD in Practice A JAVA perspective
2. Introduction - Let’s meet • Java Architect & Codesmith ‣ I ❤ OSS conferences! • Contracted by a Dutch ‘Fintech’ company • Passion for ‣ Machine learning ‣ Big Data technologies ‣ Reactive programming • Contact me on (@fbascheper) 2 My shared passion ?
3. Introduction - Let’s meet • Java Architect & Codesmith ‣ I ❤ OSS conferences! • Contracted by a Dutch ‘Fintech’ company • Passion for ‣ Machine learning ‣ Big Data technologies ‣ Reactive programming • Contact me on (@fbascheper) 3 To learn and share !
4. Today’s talk … Today’s talk … needs a background 4
5. Today’s talk … needs a background • First and foremost : Jakarta Data ❤ DDD ‣ They actually go really well together ‣ For the domain & service layer of a ‘normal’ Java-application • But… as I was preparing this presentation ‣ I started working for another customer ‣ On a “fairly new” application (~ 1 year old) ‣ And it did not have a domain layer ‣ Because it was ‘only’ translating data from one application to another … • This changed my mind … and today’s talk ! 5
6. Today’s talk … needs a background • First and foremost : Jakarta Data ❤ DDD ‣ They actually go really well together ‣ For the domain & service layer of a ‘normal’ Java-application • But… as I was preparing this presentation ‣ I started working for another customer ‣ On a “fairly new” application (~ 1 year old) ‣ And it did not have a domain layer ‣ Because it was ‘only’ translating data from one application to another … • This changed my mind … and today’s talk ! 6 DDD fi rst … JAKARTA DATA later !
7. https://commons.wikimedia.org/wiki/File:Q._mark_%28no_edit%29.jpg Let me start with … 7
8. https://commons.wikimedia.org/wiki/File:Q._mark_%28no_edit%29.jpg Let me start with … one question 8 Have you ever worked on an application without a (decent) domain model? BEEN THERE … DONE THAT … 😱 🙋
9. https://www.deviantart.com/mysticrainbowstock/art/Depths-of-Hell-50889361 From the depths of hell … 9 Meet …
10. Insidious problems in development • We are a cost centre, instead of a pro fi t centre ‣ Software development is seen as a nuisance, ‣ Not a source of strategic advantage • We are wrapped up with technologies ‣ We forget concise naming of objects ‣ Wrong abstractions & over-generalisation ‣ Strongly coupled services ‣ The ‘database’ has too much priority 10
11. Insidious problems in development • We are a cost centre, instead of a pro fi t centre ‣ Software development is seen as a nuisance, ‣ Not a source of strategic advantage • We are wrapped up with technologies ‣ We forget concise naming of objects ‣ Wrong abstractions & over-generalisation ‣ Strongly coupled services ‣ The ‘database’ has too much priority 11 WE are doing things wrong !
12. STRATEGIC DESIGN TACTICAL DESIGN Introducing … DDD-concepts 12
13. STRATEGIC DESIGN • Bounded Contexts TACTICAL DESIGN Introducing … DDD-concepts 13 • A semantic contextual boundary, where • Each component inside - Has a speci fi c meaning - And does speci fi c things
14. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language TACTICAL DESIGN Introducing … DDD-concepts 14 • A shared language • Used by all team members - Within a bounded context • To facilitate - Collaboration - Mutual understanding
15. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core domain - Supporting domain(s) - Generic domain(s) TACTICAL DESIGN Introducing … DDD-concepts 15 • Distinct areas within a domain with its own - Business logic - Requirements. • To help organize and manage the complexity of the domain.
16. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN Introducing … DDD-concepts 16 • A visual representation that illustrates - relationships & interactions between Bounded Contexts • Note: - Well-de fi ned interfaces and contracts between BC’s may change over time!
17. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects Introducing … DDD-concepts 17 • An entity models an individual thing - Has a unique identity - May be mutable / have state changes • A value object models an immutable conceptual whole over time!
18. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories Introducing … DDD-concepts 18 • Aggregates are - Composed of at least one entity - And potentially value objects • Aggregate roots own all elements clustered inside it
19. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories • Interfaces and application services Introducing … DDD-concepts 19 • Interfaces de fi ne contracts or boundaries between different parts of the system. • Application services coordinate the use cases and business logic - Act as intermediary between domain layer & user interface
20. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories • Interfaces and application services • Domain Events Introducing … DDD-concepts 20 • A domain event is a - Record of a business signi fi cant occurrence in a bounded context • Different origins - Often caused by user command - Or time based - (...)
21. STRATEGIC DESIGN • Bounded Contexts • Ubiquitous Language • (Sub) domains - Core, supporting and generic • Context maps TACTICAL DESIGN • Entities and value objects • Aggregates and aggregate roots - Repositories • Interfaces and application services • Domain Events Introducing … DDD-concepts 21
22. How to apply DDD? STRATEGIC DESIGN TACTICAL DESIGN 22 Bounded Context Problem Space Solution Space
23. Steps in Strategic Design 23 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts
24. Steps in Strategic Design 24 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts
25. https://commons.wikimedia.org/wiki/File:South_facade_of_the_Rijksmuseum_Amsterdam_%28DSCF0528%29.jpg Understanding the domain 25 A museum ! BECAUSE WE ’RE SICK OF PET SHOPS , ETC .. 🙇
26. https://nl.wikipedia.org/wiki/Drents_Museum#/media/Bestand:6J5A0353.jpg Understanding the domain 26
27. https://nl.wikipedia.org/wiki/Drents_Museum#/media/Bestand:6J5A0353.jpg Understanding the domain 27
28. Steps in Strategic Design 28 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts
29. Understanding the domain (“museum”) 29 • Entrance • Halls • Corridors • Shop • Cafe • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen Shelves Display cases Vitrines Free-standing Default route Child route ‘See everything’ route • Orders • Order lines • Product • Shopping cart • Payment
30. Understanding the domain (“museum”) 30 What exactly distinguishes a drawing from a sketch 🤔 ⁉
31. Understanding the domain (“museum”) 31 What exactly distinguishes a drawing from a sketch 🤔 ⁉ Or a vitrine from a display case ? 🤔 ⁉
32. Understanding the domain (“museum”) 32 Watch out for homonyms & synonyms ! ⚠
33. Understanding the domain (“museum”) 33
34. Steps in Strategic Design 34 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts
35. • Entrance • Halls • Corridors • Shop • Cafe Default route Child route ‘See everything’ route Shelves Display cases Vitrines Free-standing Define core and supporting domains 35 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment
36. • Entrance • Halls • Corridors • Shop • Cafe Default route Child route ‘See everything’ route Shelves Display cases Vitrines Free-standing Define core and supporting domains 36 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment CORE DOMAIN
37. • Entrance • Halls • Corridors • Shop • Cafe Default route Child route ‘See everything’ route Shelves Display cases Vitrines Free-standing Define core and supporting domains 37 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment CORE DOMAIN
38. • Entrance • Halls • Corridors • Shop • Cafe Shelves Display cases Vitrines Free-standing Define core and supporting domains 38 • Artworks • Paintings • Sculptures • Drawings • Etches • Potteries • Relics • Coins • On display • Being repaired • In storage • Missing • Stolen • Orders • Order lines • Product • Shopping cart • Payment CORE DOMAIN GENERIC DOMAIN SUPPORTING DOMAIN Default route Child route ‘See everything’ route SUPPORTING DOMAIN
39. Steps in Strategic Design 39 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts
40. https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/domain-event.png Perform Event Storming 40
41. Perform Event Storming 41 Exhibition Created Exhibition Opened to Public Artwork Moved to Exhibition space Visitor Attended Exhibition Artwork Sent for Restoration Artwork Cataloged Artwork Acquired Artwork Assigned to Exhibition Artwork Appraised Exhibition Closed Artwork Authenticated Visitor Checked In Guided Tour Booked Visitor Left Feedback Visitor Ticket Purchased
42. https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/process-modelling.PNG https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/big-picture-tools.jpg Perform Event Storming 42
43. https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/Software-picture.jpg Perform Event Storming 43 THE SOFTWARE DESIGN PICTURE THAT EXPLAINS “ALMOST” EVERYTHING …
44. https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet/blob/master/_resources/pivotal-events.PNG Perform Event Storming 44 ➡ BOUNDED CONTEXTS !
45. Steps in Strategic Design 45 1. Understand the Domain and Engage with Domain Experts 2. De fi ne the Core and Supporting Domains 3. Perform Event Storming 4. Identify Bounded Contexts
46. Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 46 Purpose: manages the lifecycle and metadata of artworks Pivotal event Marks a transition from acquisition to being part of the managed collection
47. Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 47 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public Handles the creation, scheduling, and logistics of exhibitions Pivotal event Transition from internal planning to public-facing operations.
48. Visitor Experience Context Visitor Attended Exhibition Visitor Left Feedback Guided Tour Booked Visitor Checked In Visitor Ticket Purchased Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 48 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public Purpose: Manages visitor interactions, bookings, and feedback Pivotal event Initiates the visitor journey
49. Visitor Experience Context Visitor Attended Exhibition Visitor Left Feedback Guided Tour Booked Visitor Checked In Visitor Ticket Purchased Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 49 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public High Cohesion & Low Coupling WHERE EVERY BOUNDED CONTEXT HAS ITS OWN SHARED LANGUAGE
50. Visitor Experience Context Visitor Attended Exhibition Visitor Left Feedback Guided Tour Booked Visitor Checked In Visitor Ticket Purchased Artwork Management Context Artwork Acquired Artwork Appraised Artwork Cataloged Artwork Sent for Restoration Artwork Authenticated Identify Bounded Contexts 50 Exhibition Management Context Exhibition Created Exhibition Closed Artwork Assigned to Exhibition Artwork Moved to Exhibition Exhibition Opened to Public
51. STRATEGIC DESIGN TACTICAL DESIGN Solution Space Solution Space Step up to solution space 51 Bounded Contexts Problem Space
52. Bounded Contexts as Micro Services • This is where we’re heading … 52 VISITOR EXPERIENCE EXHIBITION MANAGEMENT ARTWORK MANAGEMENT { } BACK-END
53. Bounded Contexts as Micro Services • This is where we’re heading … 53 ARTWORK MANAGEMENT EXHIBITION MANAGEMENT VISITOR EXPERIENCE VISITOR EXPERIENCE EXHIBITION MANAGEMENT ARTWORK MANAGEMENT { { } } FRONT-END BACK-END
54. Bounded Contexts as Micro Services • Martin Fowler on Micro Frontends: ‣ “An architectural style where independently deliverable frontend applications are composed into a greater whole.” 54 ARTWORK MANAGEMENT EXHIBITION MANAGEMENT VISITOR EXPERIENCE VISITOR EXPERIENCE EXHIBITION MANAGEMENT ARTWORK MANAGEMENT { { } } FRONT-END BACK-END
55. DDD - The Java perspective • We are a cost centre, instead of a pro fi t centre ‣ Software development is seen as a nuisance, ‣ Not a source of strategic advantage • We are wrapped up with technologies ‣ We forget concise naming of objects ‣ Wrong abstractions & over-generalisation ‣ Strongly coupled services ‣ The ‘database’ has too much priority 55 We were doing things wrong !
56. DDD - The Java perspective • We are a cost centre, instead of a pro fi t centre ‣ Software development is seen as a nuisance, ‣ Not a source of strategic advantage • We are wrapped up with technologies ‣ We forget concise naming of objects ‣ Wrong abstractions & over-generalisation ‣ Strongly coupled services ‣ The ‘database’ has too much priority 56 From now on, Let’s do things right ! START WITH A THOROUGH EXPLORATION OF THE DOMAIN !
57. https://www. fl ickr.com/photos/8058098@N07/2718571627 57 AND NOW WE’RE READY TO DIVE INTO THE CODE! JAKARTA DATA
58. Jakarta Data and DDD ?! • The new Jakarta Data speci fi cations introduce ‣ A new, type-safe programming model for persistence in Java. ‣ Following a Domain-Centric Approach ‣ Instead of the Entity-Centric model from JPA • So, how to leverage the core concepts of tactical DDD-patterns? ‣ Aggregates and Aggregate roots ‣ Bounded Contexts ‣ Anti-Corruption Layer 58
59. Jakarta Data goals • A uni fi ed programming model ‣ Persistence agnostic ‣ Suitable for use with - RDBMS - Non-relational databases • Using a Domain-Centric Approach ‣ Not ‘Entity’ centric (JPA) • Pluggable and Extensible 59
60. Domain centric approach ?! • Remember JPA & traditional Hibernate? ‣ JPA is `Entity` centric ‣ Using EntityManager’s methods: persist(), merge(), remove() • Whereas Jakarta Data’s `Domain centric` approach ‣ Using the Repository pattern - Closely tied to business-entities - Which may be modeled as Aggregates with a Root entity 60
61. Repository characteristics • A ‘repository’ is de fi ned in two potential ways ‣ Either by extending / implementing a built-in supertype ‣ Or by annotating methods of a class - that does not implement Jakarta Data’s built-in supertype • A ‘repository’ is Stateless • A ‘repository’ may support Pagination 61
62. Repository built-in supertypes • The DataRepository interface ‣ The root of all other built-in repository supertype interfaces. ‣ Does not de fi ne any methods by itself • The BasicRepository interface inherits from DataRepository ‣ includes the most common operations applying to a single entity ‣ including save(), delete(), and fi ndById(). • The CrudRepository interface inherits from BasicRepository, ‣ adding insert() and update() methods ‣ corresponding to the Create and Update of the CRUD pattern 62
63. Jakarta Data annotations • (Re)uses various JPA Annotations ‣ @Entity, @Id, @Embedded, (…) • Has a minimal set of its own Annotations ‣ @Repository - @Insert / @Delete / @Update - @Save - @Find ✓@By ✓@OrderBy 63 USED TO DEFINE A REPOSITORY WITHOUT USING THE BUILT-IN SUPERTYPES
64. Jakarta Data pagination • Either Offset-based pagination ‣ Using a fi xed page size ‣ Retrieves date using page number and size • Or Cursor-based pagination ‣ Relies on unique key(s) for an entity ‣ Relative to which it determines the next / prev page 64 NOTE : UNRELATED TO PL/SQL CURSORS (!)
65. https://gist.github.com/yueliu1999/76b3b349da656e5acb1ff3145fd7012e# fi le-show-me-the-code-jpeg 65 Sure thing, because I ❤ it.
66. package com.github.fbascheper.museum.artworkmgmt.domain; import jakarta.persistence.*; import jakarta.validation.constraints.*; @Entity public class Artwork { @Id @Positive(message = "ID Number must be a non-negative integer!") public long id; @Embedded @Valid public Artist artist; @Embedded @Valid public MonetaryAmount value; Using pojo’s as Entities, … 66
67. package com.github.fbascheper.museum.artworkmgmt.domain; import jakarta.persistence.*; import jakarta.validation.constraints.*; import lombok.Builder; import com.github.fbascheper.museum.artworkmgmt.constraints.AcceptedCurrencies; @Builder(toBuilder = true) @Embeddable public record MonetaryAmount( @NotNull @AcceptedCurrencies(allowedValues = { Currency.EUR }) public Currency currency, public BigDecimal amount ) implements Comparable<MonetaryAmount> { /* methods omitted */ } } … with records as value types, … 67
68. @Repository public interface Artworks extends DataRepository<Artwork, Long> { @Save Artwork save(@Valid Artwork artwork); List<Artwork> findByArtist(Artist artist); Page<Artwork> findByMonetaryAmount(MonetaryAmount amount, PageRequest pageRequest, Sort<?>... sorts); @Find List<Artwork> sorted(Sort<?>... sorts); @OrderBy(“value") Stream<Artwork> findAll(); void deleteById(long id); } … and a basic repository 68
69. https://sketchplanations.com/if-this-isnt-nice-i-dont-know-what-is 69
70. Wrap-up and take-aways • It’s imperative to take your time for strategic design ‣ Mind the morass of technologies ‣ Be wary of over-abstraction & generalisation • A concise and complete ubiquitous language is elementary ‣ Homonyms should go into different Bounded Contexts ‣ Synonyms should be avoided (use a glossary !) • Involve your domain experts ! • Jakarta Data is awesome 🤩 ‣ But just a technology (!) 70
71. Mind the ‘checklist’ ✔ Q: HOW MANY PEOPLE UNDERSTAND YOUR SYSTEM? • Nobody ? ‣ You’re probably screwed … 😳 • Only one person ? ‣ You’re probably even more screwed … 😱 ‣ (but it’s harder to admit) • A few people are reasonably competent on the whole ‣ ➡ Safer ! • Everybody knows the whole story ‣ ➡ Just Lovely !! 71 😍
72. And my “Call to Action” 72 And become a pro fi t centre ! 💰 Claim one whole day, start Event Storming (with an expert) For everyone involved …
73. http://www.thebluediamondgallery.com/handwriting/q/questions.html 73 @fbascheper.bsky.social
74. https://commons.wikimedia.org/wiki/File:Thank-you-word-cloud.jpg 74