Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How Domain-Driven Design scaled a Big Ball of ...

Kenny Baas-Schwegler
August 25, 2024
10

How Domain-Driven Design scaled a Big Ball of Mud product @ TechExcellence

Many products start out with a simple, naive model able to prove market fit. And most of the time that one model grows, because more features need to be put in at a fast pace. This can have a huge impact once the product needs to scale. Because that fast pace can turn the model into a Big Ball of Mud, and most of the time that model isn’t the most useful model to solve the core business problems anymore. Everyone in the team knows we need to change that Big Ball of Mud, but we also don’t want to close shop. We want to keep adding features to attract more customers, scale the product and turn into a profitable product. So how can we both get ourselves out of the Big Ball of Mud while also scaling the product?

In this talk, I will tell the story of how our software development team decoupled their Big Ball of Mud, to several bounded contexts all within the same monolith. I present several heuristics, practices, tools and a strategy to decouple the current model while continuously adding features to the product and gaining feedback from the customers. One of the bigger challenges was that the team had no knowledge of Domain-Driven Design, and I will show you how the team with their stakeholders started embracing DDD. Ending up with a strategy to disentangle the model, an idealised bounded context design and monitoring domain events from the bounded context that drove collaboratively drives the product roadmap.

Outline of the session:
- Introduction of the use case, it’s domain and the challenge
- Domain-Driven Design 101
- Why understanding the underlying needs was crucial
- Collaborative software design and embedding software architecture in the teams
- From output to data-driven outcomes through Domain-Driven Design

Kenny Baas-Schwegler

August 25, 2024
Tweet

More Decks by Kenny Baas-Schwegler

Transcript

  1. @kenny_baas @[email protected] How domain-​ driven design enabled scaling a big

    ball of mud product Photo by National Cancer Institute
  2. @kenny_baas @[email protected] * Simplified map - left out accepting, screening

    and billing and more... Companies with blue collar workers Temporary employees for blue collar jobs Students age 18-25 Temporary jobs able to work next to studying user Need Components visible Invisible Value Chain Licensed under https://creativecommons.org/licenses/by-​ sa/4.0/ Based on User needs Mapping and Wardley Mapping: https://teamtopologies.com/key-​ concepts-​ content/exploring-​ team-​ and-​ service-​ boundaries-​ with-​ user-​ needs-​ mapping Legend Evolution Genesis Custom build Product (+rental) Commodity (+Utility) Customer agreement Job opening Pay Email Custom ERP recruiter Fulfill jobs for the customer Looking for a job Website Job openings database ERP system Companies with blue collar workers Students age 18-25 Someone tomorrow for a quick job work a single day when I need money Hyper flex
  3. @kenny_baas @[email protected] Written in ruby on Rails over 1.5 year

    time from scratch Based on previous models from the website Uses both the website, custom ERP and SaaS ERP Reusable capabilities for FLEX to automate manual processes Looks promising and strategy is to also go live in another country Scaled up from 3 to 13 engineers, hybrid working Keep delivering new features Photo by Osman Rana on Unsplash Status of the product
  4. What do I do @kenny_baas @[email protected] Independent software consultant, tech

    lead, and software architect, catalysing organisations and teams towards designing and building sustainable and resilient software architectures. Team Topologies valued practitioner, enabling organisation to organizing business and technology teams for fast flow in combination with Domain-​ Driven Design. Enabling teams to independently undertake software design, while providing expertise to modernize their software architecture. This includes untangling and modernizing legacy software systems, as well as improving the overall product.
  5. @kenny_baas @[email protected] Agenda Domain-​ Driven Design 101 Why understanding the

    underlying needs of users was crucial Collaborative software design and embedding software architecture in the team From output to data-​ driven outcomes through Domain-​ Driven Design
  6. @kenny_baas @[email protected] It is designed to make programming web applications

    easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Rails emphasizes the use of convention over configuration (CoC) and follows the principle of Don't Repeat Yourself (DRY).
  7. @kenny_baas @[email protected] The Model is usually the boundary, where new

    features are being added to...Ending up with a Big Ball of Mud
  8. @kenny_baas @[email protected] Domain models often start based on a naïve,

    over simplified entity-​ relationship model based on reality. Good when you start, but when dealing with more complicated and complex problems it will become a big ball of mud
  9. @kenny_baas @[email protected] Platonic Domain model thinking assumes idealized, abstract representations

    of reality which may not always capture the intricacies of a domain. This can be misleading in Domain-​ Driven Design (DDD), especially in core or complicated supporting domains where the nuances matter. A naïve model, influenced by this thinking, can confine you to an oversimplified view, potentially leading to incorrect, suboptimal and unadaptable software solutions. Inspired by Barry M O'Reilly - Plato is the devil Anti-​ Pattern: Platonic Domain Model Thinking
  10. @kenny_baas @[email protected] Users and stakeholders Other people involved in designing

    and building software Managers Architects User researcher Analysts ..... Code Engineering Team
  11. @kenny_baas @[email protected] Photo by pure julia on Unsplash For each

    specific problem, a different map For each specific problem, a different model
  12. @kenny_baas @[email protected] Job template Jobs Jobs Applications Candidate applications Application

    ...... Domain-​ Driven Design allows you to break down your domain into smaller models, enabling a single team to take ownership, even within a monolithic architecture. This empowers the team to make changes more independently, as it reduces the impact of those changes on other models. Job drafting Job Fulfilment Candidate applications
  13. @kenny_baas @[email protected] Photo by oxana v on Unsplash Keep the

    shop open: Start extracting bounded context guided by the roadmap What bounded context do we touch that is on the backlog? What is something on the backlog what is hard to do with the current model?
  14. @kenny_baas @[email protected] DDD attempted (and succeeded) in giving us a

    framework to talk about good ways to design domain models and use those models in our software systems. DDD is a discipline rooted in the belief that creating good software systems for problems in the complex domain cannot be done without a deep understanding of the business problems you are trying to solve in the domain. Domain-​ Driven Design 101 - Summary
  15. @kenny_baas @[email protected] Onboarding a student Signup for an account Screen

    a candidate Upload compliancy information and documents Plan a kickstart Check student compliancy Enable on platform Student 18-25 years Work single day job when money is needed Recruiter Find the best job for a student to work on apply for a job Account service Kickstart service Screening service Compliancy service Candidate service user Need Components Legend
  16. @kenny_baas @[email protected] Anti-​ Pattern: Splitting a big ball of mud

    based on objects or process Refactoring a monolithic system by dividing it based on abstract or "platonic" object concepts can lead to a fragmented architecture, an approach that's an acknowledged anti-​ pattern. This method, focused on idealized object categories rather than concrete functionalities, often results in ambiguous module responsibilities, impractical implementations, increased maintenance overhead, and reduced adaptability to new requirements. Inspired by Barry M O'Reilly - Plato is the devil
  17. Purpose & Problems Value stream: All activities a team performs

    from understanding the purpose & problem to building that solution without being blocked Solution Feedback Stream-​aligned team: Long-​ term design + build + run for software-​ enriched services in a small, stable team of around ~5-9 people Stream-​aligned teams @kenny_baas @[email protected] 💡Stop managing dependencies start unblocking flow 💡You build it, you design and run it!
  18. @kenny_baas @[email protected] Collaborative modelling is a visualisation technique to analyse

    complex and conflict-​ laden decision-​ making processes with all relevant stakeholders and decision-​ makers to create a shared understanding.
  19. @kenny_baas @[email protected] https://www.eventstorming.com/ First time we started with only the

    team, on-​ site. Afterward we move it to a miro board, so we could continue online. EventStorming became the default modelling language to design software for the engineers. Once the engineers had a good understanding of EventStorming, we started doing session with stakeholders 1. 2. 3. 4.
  20. @kenny_baas @[email protected] ........ ........ ........ ........ ........ ........ ........ Start

    with 1 Miro board, and let the team self organise and enable structuring by splitting the miro board when needed. Giving each bounded context it's own board * Note, the team themselves decided on using miro
  21. @kenny_baas @[email protected] Distilling Bounded Context Onboarding a student Signup for

    an account Screen a candidate Upload compliancy information and documents Plan a kickstart Check student compliancy Enable on platform Student 18-25 years Work single day job when money is needed Recruiter Find the best job for a student to work on apply for a job Candidate screening Candidate compliancy Candidate management Account management Split according to the: Language Departments Users And run through the design with scenarios 1. 2. 3. user Need Components Legend
  22. @kenny_baas @[email protected] Photo by Trnava University on Unsplash Start applying

    Domain-​ Driven Design on a complicated, medium risk problem. That way the team can experiment with the new patterns safely, and get used too the paradigm shift without to much risk and organisation exposure
  23. @kenny_baas @[email protected] Understanding the user needs - summary We are

    so caught up in the solution space that we miss perspectives that we forget to understand that we miss opportunities  ​  ​  ​  ​  ​  ​ — Indi Young CC BY-​ SA: INDI YOUNG
  24. @kenny_baas @[email protected] A paradigm shift Command Bounded Context Entity Domain

    Event Event Handler Command Bounded Context Entity Domain Event Controllers (MVC or Rest)
  25. @kenny_baas @[email protected] Photo by Nima Mot on Unsplash "Pair programming

    is not just about writing code together; it's about weaving two minds into a singular thread of creativity and problem-​ solving."
  26. @kenny_baas @[email protected] Controllers (MVC or Rest) Rest request (command) Rest

    request (query) Company management Command Services Aggregate Company Registered WorkLoc ationUp dated Legacy model Rest request (query) Event Handler Do something else Database Entity table Column Column Column Updates Views Entity Reads request (command) request (query) Bubble context Controllers (MVC or Rest) Rest request (command) Rest request (query) Company management Command Services Aggregate Company Registered WorkLoc ationUp dated Legacy model Rest request (query) Event Handler Database Aggregate table Column Column Column Views Entity Reads Read entity Table Updates Column Column Column Event Handler Do something else request (command) request (query) Autonomous Bubble context
  27. @kenny_baas @[email protected] Sustainable design decisions are decisions that consider the

    sociotechnical impact of the alternatives. After designing and analysing the alternatives, you pick the one that gives you the best sociotechnical trade-​ off with the information that is available. You create a feedback loop into your design process to improve it along the way. Over time, you will find yourself making decisions in a similar way. This is when your decisions become sustainable. Collaborative software design - summary Complex Environment Sociotechnical System Structure (Organization) Adapted from "Assessing the impact of new technology on complex sociotechnical systems", South African Journal of Industrial Engineering August 2016 Vol 27(2), pp 15-29, R. Oosthuizen & L. Pretorius https://www.researchgate.net/publication/306242078_Assessing_the_impact_of_new_technology_on_complex_sociotechni cal_systems Licensed under https://creativecommons.org/licenses/by-​ sa/4.0/ People (Cognitive & Social) Physical System (Hardware, Software, Facilities) Task (Work)
  28. @kenny_baas @[email protected] Photo by Ibrahim Boran on Unsplash From output

    to data-​ driven outcomes through Domain-​ Driven Design
  29. @kenny_baas @[email protected] Job Drafting Add job Job Added Job Fullfiment

    Publish Job Job Published Cancel job Apply candidate for job Cancel application Job Cancelled Candidate applied for job Application cancelled ACL Create legacy Job Legacy model Create job Job Created Challenging the backlog....
  30. @kenny_baas @[email protected] “We can't impose our will on a system.

    We can listen to what the system tells us, and discover how its properties and our values can work together to bring forth something much better than could ever be produced by our will alone.”  ​  ​  ​  ​  ​ — Donella H. Meadows From output to data-​ driven outcomes through Domain-​ Driven Design - Summary