Building an Application with TDD, DDD and Hexagonal Architecture - Isn't it a bit too much?

Slide 1

Slide 1 text

Building an Application with TDD, DDD and Hexagonal Architecture Isn’t it a bit too much? NDC Oslo 2025 Mufrid Krilic, Domain-Driven Design Coach, CoWork, Norway

Slide 2

Slide 2 text

School class in Brunswick, Germany around 1785

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Questions at menti.com 8887 3411 Teacher gives assignment: Add up all numbers from 1 to 100

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

They all work quietly except for one…

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Johann Carl Friedrich Gauß • Probably "greatest mathematician since antiquity”

Slide 10

Slide 10 text

What to expect today? • When you doubt something, you ask questions • This goal of this talk is to provide a set of questions • Applicable for you in your context

Slide 11

Slide 11 text

• Does every business case deserve deep domain understanding? • What justifies the choice of a particular architecture? • What are the limits of the acceptable cognitive load when reading code?

Slide 12

Slide 12 text

I don’t have time for Domain-Driven Design! • It’s not about how much time we spend on modeling • It’s about testing your models • «Not every part of the system will be well-designed” - Eric Evans

Slide 13

Slide 13 text

How do we validate the choice of architecture? • When can we expect to get the feedback on the choices we take? • Complexity feedback!

Slide 14

Slide 14 text

TDD not needed everywhere • It’s about your confidence level in the code you are working with • As a rule of thumb, check your cognitive load when reading code!

Slide 15

Slide 15 text

Where I do fit in…. • “Domain-Driven Design enthusiast” • CoWork – where I work with • Tight-Loose-Tight • Domain-Driven Design • Feel free to reach out! Helping Build Domain-Driven Product Organizations

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Questions at menti.com 8887 3411 We will question three principles today • Domain-Driven Design • Deliberate choice of architecture • Test-Driven Development

Slide 18

Slide 18 text

Questioning the first principle Domain-Driven Design ….how much of domain knowledge do we need to get started?

Slide 19

Slide 19 text

Questions at menti.com 8887 3411 The Business Context • In case of an emergency and if all our traditional communication channels are unavailable, • we need a way to distribute information to all employees by SMS.

Slide 20

Slide 20 text

Questions at menti.com 8887 3411 The Business Context • The HR-system is employee data owner • “we need to connect to a SMS-gateway via API”

Slide 21

Slide 21 text

Understanding the problem space with Domain-Driven Design • Domain Analysis • Untangling the user and stakeholder needs via the domain language • Domain Modeling • 3 models! • Using the linguistic boundaries to model the application The “Blue Book” by Eric Evans - 2004

Slide 22

Slide 22 text

Questions at menti.com 8887 3411 Isn’t it a bit too much? • How much of domain analysis? • How much of domain modeling? • Well…. it depends on the complexity of the problem!

Slide 23

Slide 23 text

Questions at menti.com 8887 3411 The Business Context • In case of an emergency and • if all our traditional communication channels are unavailable, • we need a way to distribute information to all employees by SMS. • The HR-system is employee data owner • we need to connect to a SMS-gateway via API

Slide 24

Slide 24 text

Questions at menti.com 8887 3411 Ok, no DDD needed then? • Less complexity revealed than initially assumed • No domain language intricacies • How long will it take to do “modeling”, anyway?

Slide 25

Slide 25 text

First perspective Implementing the requirements

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Second perspective Can we solve the problem differently?

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Questions at menti.com 8887 3411 Language nuances! • What are Employee Groups? • It turns out that the customer’s organization is divided into multiple sub-organizations • Employees are contracted within the sub-organizations

Slide 30

Slide 30 text

Questions at menti.com 8887 3411 A bit of “DDD inspiration” is useful! • The second approach revealed the business model more clearly! • Can we get even better with the 3rd model?

Slide 31

Slide 31 text

Questions at menti.com 8887 3411 Multiple Models vs. Speed? “the only effective way to find out what customers really need is to give them what they want and do it quickly. That's why we iterate” - Jason Gorman on Mastodon

Slide 32

Slide 32 text

Questions at menti.com 8887 3411 Do we have time? • It’s not about how much time we spend on modeling • It’s about testing your models • Delivery • Scenarios

Slide 33

Slide 33 text

Questioning the second principle Deliberate Choice of Architecture ….choosing Hexagonal Architecture, but why?

Slide 34

Slide 34 text

Choosing Hexagonal Architecture From: https://alistair.cockburn.us/hexagonal-architecture/

Slide 35

Slide 35 text

Questions at menti.com 8887 3411 Choosing Hexagonal Architecture “Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases” • The intent of Hexagonal architecture by Alistair Cockburn

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Entry from the environment (AWS) and kickstarting the use case by application service

Slide 38

Slide 38 text

External Services HR System SMS Service

Slide 39

Slide 39 text

Adapters: Abstract away the dependencies on external services by defining interfaces from business perspective Business logic: Keep the HR Service Employee Organizations and SMS Service Groups in sync

Slide 40

Slide 40 text

Enforcing the architecture choice by managing the dependencies between the namespaces

Slide 41

Slide 41 text

Questions at menti.com 8887 3411 The Impact on Code Structure • We are introducing several abstraction layers • We are introducing more rigid dependency strategy • We are requiring more discipline from the developers

Slide 42

Slide 42 text

Isn’t it a bit too much? • Does the intent behind hexagonal architecture suits our project well? • More importantly: Does the insight of more business complexity justify the choice?

Slide 43

Slide 43 text

Questions at menti.com 8887 3411 How do we validate the choice of architecture? • When can we expect to get the feedback on the choices we take? • Revealing domain complexity!

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Evolutionary Software Architecture “this idea of isolating and abstracting the parts of the system that you don't yet fully understand is a cornerstone of a more evolutionary approach to software architecture, defer decisions with abstraction!” - Dave Farley

Slide 46

Slide 46 text

Business logic: Keep the HR Service Employee Organizations and SMS Service Groups up-to-date

Slide 47

Slide 47 text

Abstraction-First Approach

Slide 48

Slide 48 text

Abstraction-First Approach Where are Employees contracted today?

Slide 49

Slide 49 text

Abstraction-First Approach SMS Groups need to follow organization structure

Slide 50

Slide 50 text

Abstraction-First Approach Keeping the two data sources in sync to be able to send SMS to active recipients

Slide 51

Slide 51 text

Abstraction-First Approach Since synchronization is not trivial, we decide to summarize results in a report for human intervention

Slide 52

Slide 52 text

Questions at menti.com 8887 3411 Embracing the uncertainty and complexity! • Keeping the two systems in sync was not a trivial task at all • Abstracting the business logic in a separate layer seems to be necessary

Slide 53

Slide 53 text

Questions at menti.com 8887 3411 One abstraction at a time…. • Should we have waited to introduce Hexagonal Architecture? • Which leads us to the last principle…

Slide 54

Slide 54 text

Questioning the third principle Test-Driven Development Where do we get most value from the tests?

Slide 55

Slide 55 text

Reaching the good-enough abstraction level • “abstracting the parts of the system we don’t yet fully understand” • Dave Farley quote • Understanding through rules or examples?

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Questions at menti.com 8887 3411 Build Understanding with Examples! @Test EmployeeExistsTwiceInSameGroupWithDuplicatePhoneNumbers_DoesNotAddDuplicateNumber() SomeEmployeesWithoutPhoneNumberForReceivingSms_ReportMembersWithoutPhoneNumber() DifferentNamesWithSameNumber_ReportMemberNotAddedBecauseOtherUserInSameGroupUsesSameNumber()

Slide 58

Slide 58 text

Questions at menti.com 8887 3411 Embracing the uncertainty with TDD! • Explore the domain test-driven • Setting up scenarios that validate your understanding of the domain • Slowly revealing the complexity

Slide 59

Slide 59 text

Abstraction-First Approach

Slide 60

Slide 60 text

TDD Approach

Slide 61

Slide 61 text

What do we gain by introducing more abstractions? • Will an abstraction allow for less cognitive load? • Creating the abstraction early • Do you get more options? • Do you feel more committed to the abstraction?

Slide 62

Slide 62 text

Abstraction over HREmployeeService Reflect organization structure in SMS groups Synchronize employees and organizations with SMS groups Build a report due to all sorts of things can get out-of-sync

Slide 63

Slide 63 text

Questions at menti.com 8887 3411 So, TDD does indeed help…. • Helping us model the “parts we don’t yet fully understand” • Building one abstraction at a time • Where uncertainty is highest

Slide 64

Slide 64 text

Questions at menti.com 8887 3411 Evolving Architecture • So far, we have discovered one area of uncertainty • Does that justify the choice of Hexagonal Architecture?

Slide 65

Slide 65 text

• Keep the Domain as a separate abstraction layer • Strict dependency management on Domain • Domain does not know about anything else • Relax constraints on everything else • No constraints on dependencies flow outside the Domain • Let developers discipline evolve!

Slide 66

Slide 66 text

One more DDD lesson «Not all parts of the system will be well- designed» • Eric Evans talking about the Core Domain

Slide 67

Slide 67 text

One more DDD lesson • Exploring the domain TDD-way for the parts you intend to design well • Consider relaxing the test-first constraint on other parts

Slide 68

Slide 68 text

Questions at menti.com 8887 3411 TDD everywhere? • Effort vs. value • Uncertainty vs. standard

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

Questions at menti.com 8887 3411 TDD not needed everywhere • Testing code on the “edges” • Code falling into “standard” category • But keep cognitive load to a minimum as long as your confidence level is high

Slide 71

Slide 71 text

Wrapping up

Slide 72

Slide 72 text

Questions at menti.com 8887 3411 Domain-Driven Design Questions to Consider! • How complex is the problem space? • Deep domain analysis vs. verifying models by delivery

Slide 73

Slide 73 text

Questions at menti.com 8887 3411 Evolving Architecture vs. Deliberate Architecture Choice Questions to Consider! • Can we defer the choice of architecture? • Evolving architecture one abstraction at a time

Slide 74

Slide 74 text

Questions at menti.com 8887 3411 Test-Driven Development Questions to Consider! • Can you explore uncertainty by defining tests as examples?

Slide 75

Slide 75 text

Questions at menti.com 8887 3411 Cognitive load while reading the code Questions to Consider! • Before introducing new abstraction • What is the cognitive load while reading the code? • Will the abstraction separate logically cohesive pieces?

Slide 76

Slide 76 text

Questions at menti.com 8887 3411 Questions to Consider! • How complex is the problem space? • Deep domain analysis vs. verifying models by delivery • Can we defer the choice of architecture? • Evolving architecture one abstraction at a time • Can you explore uncertainty by defining tests as examples? • Before introducing new abstraction • What is the cognitive load while reading the code? • Will the abstraction separate logically cohesive pieces?

Slide 77

Slide 77 text

This talk was all about doubting your principles • Is there a different way to do things? • Why do I value certain principles? • Rediscover the true reason behind

Slide 78

Slide 78 text

Because…. “Those are my principles, and if you don't like them…. ... well, I have others” - Groucho Marx

Slide 79

Slide 79 text

Still Curious? • Join the workshop “Practical DDD” • Tomorrow 10:20 • Workshop Room 2 • Limited seats! Helping Build Domain-Driven Product Organizations

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

Photos • https://unsplash.com/@austriannationallibrary • Encyclopædia Britannica, Inc. • https://unsplash.com/@paul_nic • https://unsplash.com/@cosmicomicfox • https://unsplash.com/@stergro • https://unsplash.com/@theshubhamdhage • https://unsplash.com/@devsnice • www.vecteezy.com