The architectural style of our first solution could be neatly summarized as “aggregates everywhere.” Agency, campaign, placement, funnel, publisher: each and every noun in the requirements was proclaimed as an aggregate.

All of those so-called aggregates resided in a huge, lone, bounded context. Yes, a big, scary monolith, the kind everyone warns you about nowadays.

And of course, those were no aggregates. They didn’t provide any transactional boundaries, and they had almost no behavior in them. All the business logic was implemented in an enormous service layer.

When you aim to implement a domain model but end up with the active record pat‐ tern, it is often termed an “anemic domain model” antipattern. In hindsight, this design was a by-the-book example of how not to implement a domain model. How‐ ever, things looked quite different from a business standpoint.

From the business’s point of view, this project was considered a huge success! Despite the flawed architecture, we were able to deliver working software in a very aggressive time to market. How did we do it?

A kind of magic

We somehow managed to come up with a robust ubiquitous language. None of us had any prior experience in online marketing, but we could still hold a conversation with domain experts. We understood them, they understood us, and to our astonish‐ ment, domain experts turned out to be very nice people! They genuinely appreciated the fact that we were willing to learn from them and their experience.

The smooth communication with the domain experts allowed us to grasp the busi‐ ness domain in no time and implement its business logic. Yes, it was a pretty big monolith, but for two developers in a garage, it was just good enough. Again, we pro‐ duced working software in a very aggressive time to market.

1 @DDDBorat is a parody Twitter account known for sharing bad advice on domain-driven design.

Our early understanding of domain-driven design

Our understanding of domain-driven design at this stage could be represented with the simple diagram shown in Figure A-2.

Figure A-2. Our early understanding of domain-driven design