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

Slide 2

Slide 2 text

Questions at menti.com 1921 0519 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 3

Slide 3 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 4

Slide 4 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 5

Slide 5 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 6

Slide 6 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 7

Slide 7 text

Where I do fit in…. • “Domain-Driven Design enthusiast” • Consultant at CoWork • Tight-Loose-Tight • Domain-Driven Design • Developer, architect, technical coach • Healthcare, Telecom, Insurance • Feel free to reach out! www.linkedin.com/in/mufrid/ https://hachyderm.io/@mufrid [email protected] Product Development Coaching

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

Questions at menti.com 1921 0519 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 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Questions at menti.com 1921 0519 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 14

Slide 14 text

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

Slide 15

Slide 15 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 16

Slide 16 text

Questions at menti.com 1921 0519 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 17

Slide 17 text

Questions at menti.com 1921 0519 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 18

Slide 18 text

Questions at menti.com 1921 0519 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 19

Slide 19 text

First perspective Implementing the requirements

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Second perspective Can we solve the problem differently?

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Questions at menti.com 1921 0519 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 24

Slide 24 text

Questions at menti.com 1921 0519 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 25

Slide 25 text

Questions at menti.com 1921 0519 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 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Questions at menti.com 1921 0519 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 30

Slide 30 text

No content

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

External Services HR System SMS Service

Slide 33

Slide 33 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 34

Slide 34 text

Enforcing the architecture choice by managing the dependencies between the namespaces

Slide 35

Slide 35 text

Questions at menti.com 1921 0519 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 36

Slide 36 text

Questions at menti.com 1921 0519 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 37

Slide 37 text

Questions at menti.com 1921 0519 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 38

Slide 38 text

Slide 39

Slide 39 text

Questions at menti.com 1921 0519 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 40

Slide 40 text

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

Slide 41

Slide 41 text

Abstraction-First Approach

Slide 42

Slide 42 text

Abstraction-First Approach Where are Employees contracted today?

Slide 43

Slide 43 text

Abstraction-First Approach SMS Groups need to follow organization structure

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Questions at menti.com 1921 0519 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 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 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 50

Slide 50 text

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Questions at menti.com 1921 0519 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 53

Slide 53 text

Abstraction-First Approach

Slide 54

Slide 54 text

TDD Approach

Slide 55

Slide 55 text

Questions at menti.com 1921 0519 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 56

Slide 56 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 57

Slide 57 text

Questions at menti.com 1921 0519 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 58

Slide 58 text

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

Slide 59

Slide 59 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 60

Slide 60 text

Questions at menti.com 1921 0519 TDD everywhere? • Effort vs. value • Uncertainty vs. standard

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

Questions at menti.com 1921 0519 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 63

Slide 63 text

Questions at menti.com 1921 0519 One more DDD lesson «Not all parts of the system will be well- designed» • Core domain • Exploring the domain TDD-way for the parts you intend to design well • Consider relaxing the test-first constraint on other parts

Slide 64

Slide 64 text

Wrapping up

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

Questions at menti.com 1921 0519 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 69

Slide 69 text

Questions at menti.com 1921 0519 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 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

Team Mission Possible Follow the team on GitHub!

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

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