Directory Structure, Namespaces and Naming Conventions about php-ddd HOT 9 OPEN

The whole "domain layer vs application layer" is a bit of a false dichotomy anyway. Commands are domain concepts, if they actually use domain language and represent things the business needs, as opposed to vague wording like "create customer". (If you could create customers you'd be rich fast)
A command handler is function that know how to apply a command (domain) to the model (domain), so it makes sense that it would be part of that domain, except I'd never discuss command handlers with business people. The command handler can be pure domain terminology inside, but they're also a good place to put transaction logic. This is leaky, until you realise that understanding consistency and failures and rollbacks are important for a business, not just a dev, so now transactions become domain concepts.
Etcetera. The point is that it doesn't really matter in what layer something is. What I value is good, understandable domain models, where code that conceptually belongs together, lives together — eg a command that affects a change in some domain object is located close to that object. It helps me to find stuff and see at first glance what I need to know about some feature. And favour putting things together based on business processes as opposed to arbitrary structure. eg /EmployeeOnboarding/HireEmployee /EmployeeCompensation/EmployeeSalary as opposed to organising based on a big central Employee object.

from php-ddd.

I think if an aggregate grows it is fine to add some subdirectories e.g. for Events and Exceptions like this @prooph example:

• https://github.com/prooph/proophessor-do-symfony/tree/master/src/ProophessorDo/Model/Todo

But in any way I find it most important to separate code - at least inside the Domain layer - regarding Domain and not architectural terms as @theUniC stated here:

• dddshelf/ddd-in-php-book-issues#50 (comment)
• dddshelf/ddd-in-php-book-issues#50 (comment)

But even in the Application layer the @dddinphp book suggests the same approach:

• https://github.com/dddinphp/last-wishes/tree/master/src/Lw/Application/Service

I have an app with 20 Commands and Handlers and maybe it's ok to add a Command and CommandHandler folder. But for know I stay with this structure.

A lot of files actually make rethink my aggregates - maybe I should create more smaller aggregates or move stuff to other bounded contexts.

Feel free to join the discussion here too:

• dddshelf/ddd-in-php-book-issues#50

from php-ddd.

This is not the @Silex you are looking for 😉

from php-ddd.

"Fixed" @Silex ! ;)

from php-ddd.

Hi @webdevilopers,

The only reason of my folders separation is a point of view. I've started working with DDD on a big project one and I see that if I put all in a "context" folder like domain or services it will be a big bag. I divided into separated folders to keep it simple. That's the main reason!!

What do you think about that? I'm interested to learn other points of view!!

Thanks for read my little project.

from php-ddd.

Agree with you, I think that architectural and domain terms should be balanced and is useful to separate code into folders... Otherwise, the Domain will be the same... Only where to find some components will change his path but not his context.

from php-ddd.

Recently I watched "Event Sourcing: the good, the bad and the complicated" by @Ocramius:

• https://www.youtube.com/watch?v=8NuHNtwjync

At some point he states that "Command"s belong in to the Domain Layer.
I was suprised! Not only because of my previous comments and examples here about @dddinphp:

• https://github.com/dddinphp/last-wishes/tree/master/src/Lw/Application/Service

But also because of a post of him where I interpreted that I should put them into the Application Layer:

Since the command handler is part of our application layer, we are effectively diluting these checks into "less important layers".

• https://ocramius.github.io/blog/on-aggregates-and-external-context-interactions/

Looking at the current @prooph examples Commands and Handlers are both placed inside the Domain Layer. Allthough I think you can say that this Domain Layer is not "domain driven designed":

• https://github.com/prooph/proophessor-do-symfony/tree/master/src/ProophessorDo/Model/User

@codeliner explained to me:

commands are definitely part of the domain, handlers are a bit tricky. On the one hand they are glue code on the other hand they use the UL and only interact with interfaces defined by the domain. We've but them next to the commands because it is easier to understand if commands and handlers are not spread across the application. If you tend to see handlers as glue components then put them in the application layer.

What if you took all the Commands and Handlers and put them back CRUD style in a single Service?
Personally I don't think the Domain Model should know or better "care" about a Command and maybe its superficial validation.
The data can come from everywhere - Application Layer, Console whatever. It just has to know what data it is and ensure that it has been "transformed" into the Domain language e.g. Value Objects.

Maybe there is a major difference between using DDD and DDD w/ CQRS and Event Sourcing?
Since the Commands are also used to test the Events inside an Aggregate Root.

What do you guys think @mathiasverraes @carlosbuenosvinos @tjaskula?

Related:

• http://stackoverflow.com/questions/32216408/cqrs-commands-and-queries-do-they-belong-in-the-domain

from php-ddd.

from php-ddd.

Recently @vkhorikov posted a new interesting post about "Commands in Domain Layer":

• https://enterprisecraftsmanship.com/2019/01/31/cqrs-commands-part-domain-model/

Just my two cents:
Currently our Commands share the Service namespace in our Application Layer. Though they are not pure DTOs that only use primitives. Instead they have a named constructor receiving an object e.g. "Request" and then directly converting them into value objects. This removes possible converting from the Application Handler.

The reason for this is that our UI Tasks are reflected directly by the commands. That makes it easier to talt to our UI developers by "keeping them away" from our Domain Layer. ;)

Our handler than "converts" the UI Task into our "Domain intention":
PlaceOrder(Command) -> PlaceOrderHandler -> Order::place($command->orderId())

But I also agree with @tjaskula :
It can depend on the pattern used. I always put Domain Events into the Domain Layer.
And some patterns - I think the Actor pattern - does not use Handlers and directly passes Commands to Domain Models. Then I would place the Commands in my Domain Layer too.

Some thoughts on this here by @matthiasnoback:

• https://matthiasnoback.nl/2017/08/layers-ports-and-adapters-part-2-layers/#comment-4019734644
  started by @mjpvandenberg

Thanks in advance for sharing your thoughts.

Came from:

• https://twitter.com/_jubobs_/status/1091307282779066368 @jubobs
• https://twitter.com/vkhorikov/status/1090973338770526209

from php-ddd.