DomainModel vs Domain\Model namespace

[webdevilopers]

Most of the examples use the Domain\Model namespace. Inside the Modules chapter you recommend to change the namespace to DomainModel:

This style of structure uses an additional subfolder to store the services defined inside the domain
model. While this organization may make sense, our preference here is to tend not to use it, since
this way of separating code tends to be more focused on the architectural elements rather than the
relevant concepts in the model.

Wouldn't it make more sense to consequently use the recommended style? Or are the other examples easier to understand for people coming from a Java or DotNET world?

[carlosbuenosvinos]

Thanks for the question. I missed this paragraph. We finally suggest Domain\Model. The reasons are explained in the chapter. I'll let you know when fixed. Thanks again.

[webdevilopers]

Are you planning to extend the namespace for Repositories and Events too?

• Domain\Model
• Domain\Events
• Domain\Repositories

[theUniC]

No, we don't. We strongly believe that namespaces should be focused on domain terms rather to architectural terms. We strive to make clear the difference between a Domain Model and a Model coming from the M of MVC.

In the case of the structure you ask for, usually a Model is just a way to access to some remote data (external service, a relational database, a NoSQL database, etc.). Whereas a Domain Model is the solution space for a problem to solve (the Domain). This solution space can use Entities, Value Objects, Repositories, Services or Events to express terms coming from the Domain.

That's the reason why we don't like a strict separation between architectural elements. We strive to separate between domain terms.

[webdevilopers]

So you recommend the following? \Acme\Domain\Model\Order\Order \Acme\Domain\Model\Order\OrderId \Acme\Domain\Model\Order\OrderRepository \Acme\Domain\Model\Order\OrderItem (or \Acme\Domain\Model\Order\Item)

[MacDada]

We strongly believe that namespaces should be focused on domain terms

@theUniC If so, have you ever heard a Domain Expert talking about "repositories"? ;-)

• Product
• Products

No need to "repository" in the name.

[theUniC]

Yes, I have! :)

In general terms we recommend some sort of code organization more focused on the domain and less on architectural elements. Until now we've found that with this organization we get the best results. The structure that @MacDada aims for can be another possible solution and it's clearly focused on domain terms. So it's perfectly fine as well.

[dewey92]

So why don't just name it to DomainModel instead of Domain\Model when everything is eventually put in Model subfolder? I'm still struggling to understand at this juncture

[keyvanakbary]

@dewey92 Not all domain logic belongs to the Model, that's why there are Domain Services too. You'll usually end up with Domain/Model and Domain/Services :)

[webdevilopers]

Interesting point @keyvanakbary . Actually I'm putting Services and Events into the Domain\Model\Foo "module" folder.

Because Domain Services are important concepts to the Domain Model - most of the times they are used as Factories. I'm not sure they should live outside their Domain\Model\Foo namespace!

Of course there is also an Application folder with Command, Query and Handler. These could also be put into "module" folders:

• Application\Foo\DoCommand
• Application\Foo\DoQuery
• Application\Foo\DoHandler

or simply:

• Application\Service\Command
• Application\Service\Query
• Application\Service\Handler

Or without the Service folder etc.

[dewey92]

@keyvanakbary however the book suggests to put Services also in the Domain/Model subfolder as stated: While this organization (services in Domain/Service) may make sense, our preference here is to not use it, since this way of separating code tends to be more focused on the architectural elements rather than the relevant concepts in the model. This what makes me a little bit lost.

But my current setup is Domain/Model, Domain/Service, and Domain/Exception.

[danitome24]

I think that focus a little on architectural should be done because when an application grows up a lot, this could be a big bag on files and can be difficult to find and organize them. Maybe you should find the balance between domain and architectural terms.

That's my opinion, am I wrong? @webdevilopers @keyvanakbary