Project suggestion for example about php-ddd HOT 3 OPEN

Sounds great @yvoyer ! I like the use cases because they will also show the responsibilities of Aggregate Roots on shared Objects.

If we don't want to make it a Symfony App yet I would suggest to always keep a clean Domain master branch.
Later I will add Symfony in new branch. Maybe we will never merge these branches in the end.
They just share the src/Domain/... namespace.

Regarding Symfony I think I will be able to provide:

• a best practice structure for including Bundles - discussed in #6
• a Doctrine ORM ODM hybrid solution - e.g. for the "recipes" - using XML mapping without annotations or pollutin the Domain Model - discussed in #2
• usage of Symfony Forms w/ Data Transformers / Custom Types for using Value Objects and how to use them with a Command Bus. Discussed in #5 and #4.

I'm not sure yet where to put the Commands, Queries and Handlers. Currently they live in my Application folder. Because they are not Services directly related to the Domain Model.
Those kind of services would belong into the Domain folder.

Have you read the DDD in PHP book yet?
https://leanpub.com/ddd-in-php

Because it suggests an interesting structure for the Domain. E.g. using DomainModel instead od Domain\Model.

from php-ddd.

Have you read the DDD in PHP book yet?
https://leanpub.com/ddd-in-php

Yes and it's definitely a good resource on the subject.

I'll do the domain object pr, and we should be able to develop more on the structure before merging it in master.

About the symfony app, I would put it in the infrastructure context.

The bus and command could also be in infrastructure and do the mapping between the app and domain.

from php-ddd.

Are you sure about the Infrastructure? In DDD in PHP chapter 11.1 it says:

As Vaughn Vernon says, “Application Services are the direct clients of the domain model”. You could think about an Application Service as a point of contact between the outside world (html forms, API clients, command line, frameworks, UI, etc.) and the Domain Model itself.

There is also an example of an DTO with this namespace:
namespace Lw\Application\Service\User;

It continues in chapter 11.3 Anatomy of an Application Service.

@willdurand also commented on this:

Forms + Validation are part of the Presentation Layer. The Application Layer leverages this layer to get data, then creates a DTO (Application Layer), and calls a Factory (Application Service) to create an Entity (aggregate) using the DTO.

http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/#comment-994246916

But it was an alternative to the Command Bus - to the examples by @mathiasverraes:
http://verraes.net/2013/04/decoupling-symfony2-forms-from-entities/

I agree with @beberlei:

Commands and Handlers are part of the Service-Layer, wrapped by some dispatcher (the CommandBus in the blog post you mentioned). Handlers are sort of the Services.

I think he relates to the Application Layer Services, not the Domain(Model) Layer.

A the bottom line I don't think a Symfony Bundle fits into Infrastructure, Application or UserInterface / Presentation. The functionality should be separated.

Infrastructure:

• Persistence
• Logging

UserInterface / Presentation:

• Controllers
• Views
• Forms

Application:

• Command, Queries and Handlers

Domain(Model):

• Domain Models (becoming ORM Entities using XML Mapping from the Infrastructure Layer).

We need more feedback on this! ;)

from php-ddd.