Construction of DDD object knowledge

Question

I found on github an example project on Vaughn Vernon’s D.O.D. I haven’t had a chance to buy his book yet and read it all, but one thing I’m curious about is the fact that there are many different objects being defined. And when I speak many are many even.

In one of its delimited contexts there are 68 objects. And this I’m talking only about the domain model, not to mention other necessary objects. When I speak object I am simply wanting to generalize: this includes entities, value objects, aggregates, repositories, etc.

The question that generated me was this: I particularly find it humanly impossible to start an application and know that to do what she has to do it will take so many objects like this. When I saw this I thought "okay, but how would I know you need all this?"

And that’s where I want to know: does the identification of these objects come directly from ubiquitous language and why does it matter? That is, they necessarily represent concepts present in ubiquitous language?

And mainly, is knowledge of these objects built iteratively? That is, we are not expected to know all this at first, at first we know only a part and then at each iteration with the advance of understanding the domain we understand which other objects are needed?

Answer 1

It is impossible to start an application and know that for it to do what it has to do it will take so many objects.

---

The identification of these objects comes directly from the ubiquitous language and therefore its importance. That is, they necessarily represent concepts present in ubiquitous language .

---

And mainly, the knowledge of these objects is built iteratively. That is, we are not expected to know all this at first, at first we know only a part and then at each iteration with the advance of understanding the domain we understand which other objects are needed.

---

As you can see, I’ve turned your questions into affirmations, and here’s your answer.

It is fundamental characteristic of the DDD that the knowledge of the domain be deepened throughout the project, and the models will be refactored and evolved as more is learned about the domain - what happens during the project and not only at the beginning of it.

This is also characteristic of any project Agile.

As to having many objects is due precisely to the fact that a DDD project aims to solve a complex problem, and a complex problem always has many elements.

Attentive:

Just like all the good ideas in our industry, Ddd has the goal of putting to think much more than delivering chewed.

Suggestion: read the Eric Evans' book - This is the DDD birth certificate. You’ll be out with all your 200 current questions answered and you’ll get another two thousand new questions. And this will be a great experience.