Our management was looking for a profitable new vertical. They decided to try using our ability to generate a massive number of leads and sell them to smaller clients, ones we hadn’t worked with before. This project was called “marketing hub.”

Since management had defined this business domain as a new profit opportunity, it was clearly a core business domain. Hence, designwise, we pulled out the heavy artil‐ lery: event-sourced domain model and CQRS. Also, back then, a new buzzword, microservices, started gaining lots of traction. We decided to give it a try.

Our solution looked like the implementation shown in Figure A-7.

Figure A-7. A microservices-based implementation of the marketing hub bounded context

Small services, each having its own database, with both synchronous and asynchro‐ nous communication between them: on paper, it looked like a perfect solution design. In practice, not so much.

Micro what?

We näively approached microservices thinking that the smaller the service was, the better. So we drew service boundaries around the aggregates. In DDD lingo, each aggregate became a bounded context on its own.

Again, initially this design looked great. It allowed us to implement each service according to its specific needs. Only one would be using event sourcing, and the rest would be state-based aggregates. Moreover, all of them could be maintained and evolved independently.

However, as the system grew, those services became more and more chatty. Eventu‐ ally, almost each service required data from all the other services to complete some of its operations. The result? What was intended to be a decoupled system ended up being a distributed monolith: an absolute nightmare to maintain.

Unfortunately, there was another, much more fundamental issue we had with this architecture. To implement the marketing hub, we used the most complex patterns for modeling the business domain: domain model and event-sourced domain model. We carefully crafted those services. But it all was in vain.

The real problem

Despite the fact that the business considered the marketing hub to be a core subdo‐ main, it had no technical complexity. Behind that complex architecture stood a very simple business logic, one so simple that it could have been implemented using plain active records.

As it turned out, the businesspeople were looking to profit by leveraging our existing relationships with other companies, and not through the use of clever algorithms.

The technical complexity ended up being much higher than the business complexity. To describe such discrepancies in complexities, we use the term accidental complexity, and our initial design ended up being exactly that. The system was overengineered.