One trick to nail your Domain, Everytime !

Bending the Clean Architecture Principles

Introduction

What’s fascinating about development is that very often, we come back and re-embrace some concepts as totally new. You would literally find something that was invented years ago the “new norm” in the community.

DDD was invented years back and is now implemented in most of our solutions. While DDD can be great, i think it’s slightly overrated and used out of context in lots of project… This is subject to another topic so let’s focus on the positives and ignore my ranting..!

Why does it matter

In most applications, the team would be given some sort of requirements or features to implement and a planned deadline. If you’re in Agile, your team wants to finish a list of tickets in your planned sprint. When you’re doing DDD, you’re basically building a business brain that will be used by one or multiple applications.

Building that brain takes time, and in most of my experiences, the same team would collapse while building this brain for the following reasons:

• Interrupting a planned spring with sudden unexpected requirements, or an urgent feature request or anything of the sort.
• Vague, undefined business requirements: My team would spend a whole week just researching why this feature is planned, what does it serve and how it should be implemented in the business.