The most common misconception about Domain-Driven Design is that it is about code. People read about Aggregates, Entities, Value Objects, and Repositories, and they conclude that DDD is a set of patterns to apply to their codebase. They start renaming their services, wrapping their models, and calling it DDD.

It is not DDD.

DDD is a methodology for learning. Its central insight — the one that Eric Evans built the whole book around — is that the biggest problem in software is not the code. It is the gap between what the business knows and what the developers know.

Every codebase starts with good intentions.

You write clean services, keep your controllers thin, and promise yourself the business logic will stay in one place. Then the codebase grows. A deadline arrives. A rule that should belong to the domain ends up in a controller. A constraint that everyone agrees on gets copy-pasted into three different places. The code and the business start speaking different languages — and every change becomes a translation exercise.

I built Ontologic because I kept running into this problem, and I wanted a principled way out of it.

There is no single correct way to do Domain-Driven Design.

DDD is a set of ideas, not a specification. Eric Evans wrote a book. Other people wrote other books. Practitioners have been arguing about the details for twenty years, and the arguments are productive — because the domain you're modelling, the team you're working with, and the constraints you're under all genuinely affect what good DDD looks like in your specific situation.

Ontologic is my way of doing it. I want to be transparent about that.