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

Many experienced developers are longing for an opportunity to build an application from scratch. Compared to the heavy legacy applications that you might be dealing with on a daily basis, which are seen as filled with technical debt and incomprehensible architecture and design choices, a fresh start promises that you can finally write code and build an application in “the right way.”

This was exactly the opportunity my colleague and I recently got and with high motivation we applied many of the principles that we highly value, such as Test-Driven Development and Domain-Driven Design. On the other hand, experience has taught us that complexity in the code creeps in regardless. We wondered then if the very principles we based ourselves on, could actually contribute to making the code harder to read and maintain in the long run?

This presentation will show how we built a backend application for integration between three different systems based on TDD, DDD and hexagonal architecture. Along the way, we have assessed the complexity of the solution and asked ourselves some questions:

Have our decisions about isolation of the domain model and abstraction layer between the systems led to less or greater complexity?
What constitutes a domain model?
What about deliberately reduced test coverage on selected parts of the code?

The presentation will conclude with a balanced look at the decision-making process we used while we were writing code and whether it was worth applying “best practices” to this application at all.

Transcript

1. 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
2. About myself…. • Developer, architect, technical coach • Healthcare, Telecom, Insurance • “Domain-Driven Design enthusiast” • CoWork • Tight-Loose-Tight Change with Confidence
3. Some light reading
4. 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
6. 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
7. Questions at menti.com 7786 0494 Because…. “Those are my principles, and if you don't like them…. ... well, I have others” - Groucho Marx
8. 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
9. Questions at menti.com 7786 0494 We will question three principles today • Domain-Driven Design • Deliberate choice of architecture • Test-Driven Development
10. Questioning the first principle Domain-Driven Design ….how much of domain knowledge do we need to get started?
11. 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
12. 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
13. 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!
14. 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
15. 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?
16. First perspective Implementing the requirements
18. Second perspective Can we solve the problem differently?
20. 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
21. 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?
22. 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
23. 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
24. Questioning the second principle Deliberate Choice of Architecture ….choosing Hexagonal Architecture, but why?
25. 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/
27. Entry from the environment and kickstarting the use case by application service
28. External Services HR System SMS Service
29. 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
30. Enforcing the architecture choice by managing the dependencies between the namespaces
31. 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
32. 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?
33. 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!
34. 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
35. Questions at menti.com 7786 0494 Business logic: Keep the HR Service Employee Organizations and SMS Service Groups in sync
37. 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
38. 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
39. 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
40. 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…
41. Questioning the third principle Test-Driven Development Where do we get most value from the tests?
42. 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?
43. 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
44. Questions at menti.com 7786 0494 Build understanding by examples @Test EmployeeExistsTwiceInSameGroupWithDuplicatePhoneNumbers_DoesNotAddDuplicateNumber() someEmployeesWithoutPhoneNumberForReceivingSms_ReportMembersWithoutPhoneNumber() DifferentNamesWithSameNumber_ReportMemberNotAddedBecauseOtherUserInSameGroupUsesSameNumber()
45. 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
46. 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
47. 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
48. 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?
49. • 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!
50. Why not introduce more abstractions! • Since we have some complexity in the domain layer
51. Well, no… Let’s keep it like this
52. 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?
53. Questions at menti.com 7786 0494 TDD everywhere? • Effort vs. value • Uncertainty vs. standard
55. 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
56. Wrapping up
57. 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
58. 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
59. Questions at menti.com 7786 0494 Test-Driven Development Question Set Takeaway! • Can you explore uncertainty by defining tests as examples?
60. 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?
61. 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?
62. 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
64. 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