Primitive types only in command

[webdevilopers]

When I started decoupling from Symfony Form and the EntityType I switched to primitive types only that would then be used on the data_class which is the Command / DTO.

In conlusion my command only uses integers (for IDs) and strings (also UUID) or arrays of these types.

I'm sometimes asked if objects e.g. value objects should be used. As I mentioned I don't use objects in a DTO at all. As @jeremyb states in his slides:

Tips #3: Command & Value Object

Il est recommandé d'utiliser des types primitifs si la Command doit être traitée en asynchrone (à cause de la serialization)
Passer des Values Objects à une Command permet de réutiliser un cadre et les validations définies

• http://jeremybarthe.com/slides/2016-after-work-ddd-command-bus/#/32

Most examples I see follow these "guidelines":
https://github.com/SimpleBus/MessageBus/blob/master/doc/command_bus.md#using-the-command-bus-an-example @matthiasnoback

Sometimes a DTO property transfers a string coming from a constant:

class ContractState
{
    const STATE_ACCEPTED        = 'contract_accepted';
    const STATE_APPROVED        = 'contract_approved';
    const STATE_QUOTE_SUBMITTED = 'quote_submitted';
    const STATE_IN_PROGRESS     = 'in_progress';
    const STATE_PENDING         = 'pending';
    const STATE_CLOSED          = 'closed';
}

People ask how to ensure (validate) that the string $contractState of the DTO is a correct string from the constants.

If you are using Symfony Form you already set the choices and a user cannot select a different choice.

When the input comes directly from the Request I guess you could add a custom Constraint to the Command that could check if the strings exists:

• http://jeremybarthe.com/slides/2016-after-work-ddd-command-bus/#/12

Since I'm using Symfony Form I prefer validating the input inside the Value Object. The handler will try to create an object from String:

ContractState::fromString($command->contractState());

The fromString method then will throw an Exception if the string was invalid.

What are your thoughts on this?

Related issues:

• Using a Command as DTO to populate Symfony Form #5

[webdevilopers]

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

[matthiasnoback]

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.

[webdevilopers]

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

[mablae]

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.

[matthiasnoback]

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 ;)).

[webdevilopers]

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".

[mablae]

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

[webdevilopers]

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

• Directory Structure, Namespaces and Naming Conventions #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

[webdevilopers]

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

[matthiasnoback]

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.

[webdevilopers]

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!

[matthiasnoback]

Cool, you're welcome.

[webdevilopers]

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/