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? Booster Conference 2024 Mufrid Krilic, Domain-Driven Design Coach, CoWork, Norway

Slide 2

Slide 2 text

About myself…. • Developer, architect, technical coach • Healthcare, Telecom, Insurance • “Domain-Driven Design enthusiast” • CoWork • Tight-Loose-Tight Change with Confidence

Slide 3

Slide 3 text

Some light reading

Slide 4

Slide 4 text

What we will be talking about? • Domain-Driven Design • Does every business case deserve deep domain understanding? • Deliberate Choice of Architecture • What justifies the choice of a particular architecture? • Test-Driven Development • Limiting cognitive load as an alternative

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Questions at menti.com 7786 0494 This talk is about doubting your principles • Is there a different way to do things? • Why do I value certain principles? • Rediscover the true reason behind

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Questions at menti.com 7786 0494 What to expect today? • When you doubt something, you ask questions • This goal of this talk is to provide a set of questions • Applicable in other circumstances

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Questions at menti.com 7786 0494 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 12

Slide 12 text

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

Slide 13

Slide 13 text

Questions at menti.com 7786 0494 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 14

Slide 14 text

Questions at menti.com 7786 0494 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 15

Slide 15 text

Questions at menti.com 7786 0494 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 16

Slide 16 text

First perspective Implementing the requirements

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

Second perspective Can we solve the problem differently?

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

Questions at menti.com 7786 0494 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 21

Slide 21 text

Questions at menti.com 7786 0494 A bit of “DDD inspiration” is useful! • No “proper” domain modeling, however…. • The second approach revealed the business model more clearly! • Can we get even better with the 3rd model?

Slide 22

Slide 22 text

Questions at menti.com 7786 0494 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 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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 From: https://alistair.cockburn.us/hexagonal-architecture/

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Entry from the environment and kickstarting the use case by application service

Slide 28

Slide 28 text

External Services HR System SMS Service

Slide 29

Slide 29 text

Ports: 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 30

Slide 30 text

Enforcing the architecture choice by managing the dependencies between the namespaces

Slide 31

Slide 31 text

Questions at menti.com 7786 0494 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 32

Slide 32 text

Questions at menti.com 7786 0494 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 33

Slide 33 text

Questions at menti.com 7786 0494 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 34

Slide 34 text

Slide 35

Slide 35 text

Questions at menti.com 7786 0494 Business logic: Keep the HR Service Employee Organizations and SMS Service Groups in sync

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 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 38

Slide 38 text

Questions at menti.com 7786 0494 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 39

Slide 39 text

Questions at menti.com 7786 0494 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 on X/Twitter

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 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 43

Slide 43 text

Slide 44

Slide 44 text

Questions at menti.com 7786 0494 Build understanding by examples @Test EmployeeExistsTwiceInSameGroupWithDuplicatePhoneNumbers_DoesNotAddDuplicateNumber() someEmployeesWithoutPhoneNumberForReceivingSms_ReportMembersWithoutPhoneNumber() DifferentNamesWithSameNumber_ReportMemberNotAddedBecauseOtherUserInSameGroupUsesSameNumber()

Slide 45

Slide 45 text

Questions at menti.com 7786 0494 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 46

Slide 46 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 47

Slide 47 text

Questions at menti.com 7786 0494 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 48

Slide 48 text

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

Slide 49

Slide 49 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 • Let developers discipline evolve!

Slide 50

Slide 50 text

Why not introduce more abstractions! • Since we have some complexity in the domain layer

Slide 51

Slide 51 text

Well, no… Let’s keep it like this

Slide 52

Slide 52 text

Questions at menti.com 7786 0494 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 53

Slide 53 text

Questions at menti.com 7786 0494 TDD everywhere? • Effort vs. value • Uncertainty vs. standard

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

Questions at menti.com 7786 0494 TDD not needed everywhere • Testing code on the “edges” • Code falling into “standard” category • But keep cognitive load to a minimum

Slide 56

Slide 56 text

Wrapping up

Slide 57

Slide 57 text

Questions at menti.com 7786 0494 Domain-Driven Design Question Set Takeaway! • How complex is the problem space? • Deep domain analysis vs. verifying models by delivery

Slide 58

Slide 58 text

Questions at menti.com 7786 0494 Evolving Architecture vs. Deliberate Architecture Choice Question Set Takeaway! • Can we defer the choice of architecture? • Evolving architecture one abstraction at a time

Slide 59

Slide 59 text

Questions at menti.com 7786 0494 Test-Driven Development Question Set Takeaway! • Can you explore uncertainty by defining tests as examples?

Slide 60

Slide 60 text

Questions at menti.com 7786 0494 Cognitive load while reading the code Question Set Takeaway! • Before introducing new abstraction • What is the cognitive load while reading the code? • Will the abstraction separate logically cohesive pieces?

Slide 61

Slide 61 text

Questions at menti.com 7786 0494 Question Set Takeaway! • 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 62

Slide 62 text

Thank You! • Feel free to reach out! www.linkedin.com/in/mufrid/ https://hachyderm.io/@mufrid mufrid@cowork.no With Courage to Make Changes Change with Confidence

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

Questions at menti.com 7786 0494 Photos • https://unsplash.com/@paul_nic • https://unsplash.com/@cosmicomicfox • https://unsplash.com/@stergro • https://unsplash.com/@theshubhamdhage • https://unsplash.com/@devsnice • www.vecteezy.com