Primitive types only in command about php-ddd HOT 13 OPEN

Even though I'm often not actually serializing DTO's, I like them to be very flat, since that's in the spirit of a DTO. Any type of object would not be able to cross application boundaries (within the application it would probably cause incorrect coupling and to the world outside it would be completely impossible ;)).

from php-ddd.

My general rule is to have only immediately serializable data in a DTO (that is, primitive types). I know some people who add "getters" to a DTO which produce actual (domain) objects based on those primitive values. I don't do it like that, but always explicitly convert to objects inside the command handler.

from php-ddd.

I'm using commands and view models which have primitive types and won't throw any exceptions. I think this is a useful aspect of them. For commands it's very useful because now (if you use Symfony) the Form component can populate it, and validate it afterwards. Then if you pass the command to the application service, it will use the raw data from the command to construct value objects and entities. So any violations of domain invariants will appear in the application service only.

from php-ddd.

What about dates? Should they be passed as ImmutableDateTime objects or as primitive strings?
What do you think @matthiasnoback?

from php-ddd.

Agree! But do you even handle dates as strings instead of DateTimeImmutable?

from php-ddd.

Having them always serializable is good for offloading to external queue.

If serializing with an serializer like symfony/serializer or jms' it should be fine to even use object types as properties since they would be denormalized as expected. DateTime would be no problem then.

from php-ddd.

Thanks for your opinion!

Currently I'm using DateTime objects in my DTO. But I will switch to a string yyyy-mm-dd transfer.

For now most of my commands are populated by Symfony Forms (e.g. via LexikFormFilterBundle by @lexik) using the data_class.
But soon we will have primitive request parameters e.g. JSON format. Not sure if the UI would actually pass a Javascript Date object. But most of the times dates come from datepickers that return the desired string.

Converting the date strings to DateTime objects in my handler instead will make my commands flexible for any format resp. "application boundaries".

from php-ddd.

@webdevilopers DateTime::ATOM can be parsed by php and js natively.

from php-ddd.

Even though I'm often not actually serializing DTO's, I like them to be very flat, since that's in the spirit of a DTO. Any type of object would not be able to cross application boundaries (within the application it would probably cause incorrect coupling and to the world outside it would be completely impossible ;)).

I've been using Commands w/ value objects form a long time. But now that we are working with DTOs for read models from projections in a DDD CQRS environment I'm thinking about switching back again.

Recently there is discussion going on wether Commands (and Handlers) belong to the Domain Layer too:
#32

Currently having Commands using Value Objects would even support this Credo.
But moving back to a DTO with primitive would clearly separate it from the Domain Layer keeping it in the Application Layer.

And that makes it easier for our UI team to identify tasks:

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())

• #32 (comment)

In the end the Application Layer somehow has to be aware of the Domain Layer. At least when transforming the primitive types to Value Objects and then pass them to the Domain Model.

Though I think "Actor Models" also directly accept the Commands inside the Model and then transform them there. The Application Layer and orchestration is "skipped".

Any thoughts about that?

Similar discussion:

• https://stackoverflow.com/questions/4869473/value-objects-in-cqrs-where-to-use
• https://softwareengineering.stackexchange.com/questions/378909/in-what-layer-are-the-dtos-stored-with-cqrs

from php-ddd.

Another advantage of moving the validation of creating object to the Handler would be the improvement of catching errors in a single place e.g.:
#4

from php-ddd.

That is exactly the approach I would like to use @matthiasnoback in the future.
Besides the validation it will also make it easier to work with my team since some members ca focus and designing the Controllers in a different Layer / Namespace maybe.

Thanks for the feedback!

from php-ddd.

Cool, you're welcome.

from php-ddd.

We are currently decoupling our UI from our (mostly Symfony w/ Forms) applications. Now we no longer separate between a "CommandDTO" and the actual "Domain Command". The latter is sometimes directly passed to an aggregate root.

This solution by @vkhorikov works fine for us:

1. A controller receives a ChangedEmailDto from the external client. Because that’s a DTO, meaning that its sole purpose is to transfer data from one application to another, it consists of primitive types only.

2. The controller transforms the DTO into a command by converting some of the primitives into Value Objects (string email into Email email in the above example, where Email is a Value Object) and passes that command to a command handler (the application services layer).

3. The command handler executes the command by coordinating the work between domain classes (including the already dehydrated Email Value Object).

4. The domain model generates domain events. Domain events may also contain value objects — for the same reasons commands do, since both commands and domain events reside at the same level of abstraction in the onion architecture.

5. The app services layer converts the domain events into messages on the message bus. Those messages are plain DTOs too because their sole purpose is to communicate the email change to other systems.

• https://khorikov.org/posts/2019-07-31-commands-primitives/

from php-ddd.