Reflecting on DDD - Domain-Driven Design

Four months ago, I joined a startup working on greenfield projects that applied Domain-Driven Design (DDD) to solve business problems using C# on .NET. I was new to both the language and DDD, although not entirely new to Object-Oriented programming, having written Java before albeit in a non-production environment. Cue a lot of learning.

Things expectedly went over my head during the first couple of weeks. I had a lot of questions, the biggest of them being the terminology: fat events, thin events, aggregates, domain model, service events, bounded contexts, context mapping, the list goes on. As it turns out, you don’t just implement DDD. You need to understand the concepts behind it to be able to fully appreciate it. It is a development solution that is loaded with terminology and the existing codebases already reflected this through and through. Without the knowledge of DDD, it was easy to question the naming conventions in the codebase; a lot of it was DDD in practice.

After two and a half months of building an entire business domain myself, I became initiated. Although I had been recommended two DDD books to read (Domain-Driven Design Distilled and Implementing Domain-Driven Design, both by Vernon Vaughn), I’ve not had time to give them that much attention, so I’ve pretty much learned by observing, doing, and filling knowledge gaps by reading short articles. Here are my takeaways.

Codebase Architecture Mirrors the Business

If you understand the core business, you’d easily understand why the codebase has been organised in a certain way, with bounded contexts representing the different parts of the business. In fact, if you attended a meeting with product managers or the domain experts, you’d almost think they crafted the codebase themselves.

Speaking the Language of the Business in Code

The codebase is riddled with the language of the business which, in DDD terms, is referred to as the ubiquitous language. This is emphasised even more with the benefit of C# as an OOP language, making it easy to model the business accordingly.

Collaboration between the Business and Developers

There’s good collaboration between the business and developers. If you’ve been to meetings with the domain experts and worked on the codebase, they’re almost like one and the same. The business has a high-level knowledge of how the codebase has been structured and seem to naturally consider this as a factor when new features are requested. In short, they’re very involved in almost every stage of development. DDD makes it easier to prioritise the business needs during the development process.

Modelling Meetings

Meetings with the business would often involve sketching out, defining, and refining domains, subdomains, and bounded contexts. There’s a lot of transparency between the tech team and the business. Also, DDD involves quite a lot of decision-making on modelling and the name of things, which can often translate to several long meetings not just with the business but amongst developers. It however seems to pay off and make the codebase more maintainable.

Learning DDD in Practice

Just over a month into the job, I had the privilege of being asked to build out an entire domain. Needing data from other domains meant I had to dive deeper into event sourcing within other domains based on the requirements of the new domain I was building. A lot of thought went into deciding whether event messages should be fat or thin; or what domain should own which logic. It involved a lot of design and modelling decisions.

Domain-Driven Design seems to require quite a lot of time and effort than your regular development. You don’t simply go and write code. You don’t just name things as you deem fit. It needs to be agreed upon. It needs to be a collaborative effort. It needs to be a language the team speaks and understands. It needs to be the language of the business. It simply needs to mirror the business.