Learning to Love DDD - A Tale of Two Products

NOTE: This post was originally published in an older version of the blog. While all efforts were made in the migration to ensure the links still work and other visual elements communicate the intended meaning, some issues may remain. If you identify any, please drop me a note and I'll get it fixed asap.

Learning to Love DDD - A Tale of Two Products

January 11, 2023

Domain-Driven Design, Architecture, Conferences, Speaking

Learning to Love DDD - A Tale of Two Products is a conference talk I started delivering in 2022.

In some respects, it's a love letter to Domain-Driven Design after years of building systems both with and without the practice. See below for videos of the talk at a few conferences.

Talk Description

Over the last 16 years, I've been fortunate enough to help launch two successful businesses as a hands-on CTO/co-founder & developer/architect.

The first, Flexischools, provides online services to schools & parent communities, and has supported millions of Australians over the years.

When we launched Flexischools, I was relatively inexperienced - I did my best to follow the guidance I could find online, but I frequently found myself struggling to incorporate the burgeoning growth in complexity of its feature-set into an increasingly tightly coupled code-base with a very small team of developers.

In 2015, I discovered DDD, and when reading the Blue Book, I felt a light bulb going off on every page. When we launched our second product, LanternPay, I vowed not to make the same mistakes.

LanternPay is a healthcare & disability claiming & payments platform supporting hundreds of thousands of Australian care providers and recipients to ensure prompt and equitable access to care.

In this talk, I'll reflect on the comparative experience of launching, operating & scaling both products and the impact DDD had on the technology & the business.

Some key questions we'll explore:

How to use DDD when you're launching a new product into a new market and there are no domain experts to consult?
Why it's not a good idea to use the same object/table to store both the size of a school uniform t-shirt and the presence of a slice of cheese on a sandwich
How to make the business case for a major multi-service refactor when your DDD-inspired domain understanding evolves mid-project