Consider some basic rules and typical issues to pay attention to when implementing modules:

• Namespaces should be named in terms of Ubiquitous Language.
• Don't name your namespaces based on patterns or building blocks (Value Objects, Services, Entities, and so on).
• Create namespaces so that what's inside is as loosely coupled with other namespaces as possible.
• Refactor namespaces the same way as your code. Move them, rename them, group them, extract them, and so on.
• Don't use commercial product names, as they can change. Stick to the Ubiquitous Language.

We've placed the Order and the OrderLine Entities, the OrderLineWasAdded and the OrderWasCreated Event, and the OrderRepository into the same subfolder Domain/Model. This structure may be fine, but that's because we still have a simple model. What about the Bill Entity and its Repository? Or the Waybill Entity and its respective Repository? Let's add all those elements and see how they fit into the actual code structure:

While this style of code organization could be fine, it can become non-practical and rather unmaintainable in the long run. Every time we iterate and add new features, the model will become even bigger, and the subfolder will be eating even more code. We need to split the code in a way that give us a perspective of the model at a glance. No technical concerns, just Domain concerns. To reach this, we can split the model using the Ubiquitous Language, by finding meaningful concepts that help us group elements logically in terms of the Domain.

To do this, we could try the following approach:

This way, the code is more organized, conceptually speaking. And as Eric Evans points out in the Blue Book, modules are a way to communicate, as they provide us with insights about how the Domain Model works internally, along with helping us increase the cohesion and decrease the coupling between the concepts. If we look at the previous example, we can see that the concepts Order and OrderLine are strongly related, so they live in the same module. On the other hand, Order and Waybill, although sharing the same context, are different concepts, so they live in different modules. Modules are not just a way to group related concepts in the model, but also a way to express part of the design of the model.