$30 off During Our Annual Pro Sale. View Details »

Building an Application with TDD, DDD and Hexag...

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.

Mufrid Krilic

March 25, 2024
Tweet

More Decks by Mufrid Krilic

Other Decks in Programming

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. 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
  4. 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
  5. Questions at menti.com 7786 0494 Because…. “Those are my principles,

    and if you don't like them…. ... well, I have others” - Groucho Marx
  6. 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
  7. Questions at menti.com 7786 0494 We will question three principles

    today • Domain-Driven Design • Deliberate choice of architecture • Test-Driven Development
  8. 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
  9. 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
  10. 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!
  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. 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?
  13. 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
  14. 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?
  15. 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
  16. 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
  17. 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/
  18. 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
  19. 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
  20. 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?
  21. 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!
  22. 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
  23. Questions at menti.com 7786 0494 Business logic: Keep the HR

    Service Employee Organizations and SMS Service Groups in sync
  24. 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
  25. 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
  26. 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
  27. 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…
  28. 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?
  29. 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
  30. Questions at menti.com 7786 0494 Build understanding by examples @Test

    EmployeeExistsTwiceInSameGroupWithDuplicatePhoneNumbers_DoesNotAddDuplicateNumber() someEmployeesWithoutPhoneNumberForReceivingSms_ReportMembersWithoutPhoneNumber() DifferentNamesWithSameNumber_ReportMemberNotAddedBecauseOtherUserInSameGroupUsesSameNumber()
  31. 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
  32. 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
  33. 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
  34. 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?
  35. • 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!
  36. 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?
  37. 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
  38. 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
  39. 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
  40. Questions at menti.com 7786 0494 Test-Driven Development Question Set Takeaway!

    • Can you explore uncertainty by defining tests as examples?
  41. 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?
  42. 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?
  43. 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