Value Objects in Commands

[ashic]

Do you guys use primitives in commands or value objects? Do you treat commands as DTOs? Do you treat value objects as DTOs? Or do you keep all value objects hidden from the command-issuer?

[Greg Young]

I might make some structures in my messages assemby that get used by messages (or use types in xml etc) but never value objects from the domain model

On Thu, Mar 22, 2012 at 1:12 PM, ashic <ashic....@gmail.com> wrote:

Do you guys use primitives in commands or value objects? Do you treat commands as DTOs? Do you treat value objects as DTOs? Or do you keep all value objects hidden from the command-issuer?

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[ashic]

Do you have the command handler map the "UI object" to a domain value object? Would you use an "evil helper" for this? Perhaps an extension method in the command handler assembly? Or would you have a method on the message to convert to a domain VO? (for example, if the thing in question was Money[amount, currency, date] that mapped one to one between UI code and domain code)

[Yevhen Bobrov]

I'm creating map methods on message objects in such cases ...

22 марта 2012, в 19:30, ashic <ashic....@gmail.com> написал(а):

[@yreynhout]

Primitives + composites (custom data types composed of primitives) + various "intelligent" string fomats (and a lot of prior art from the xml space)

Implicit conversion operator (contracts as partial classes) to keep the typing down to get a value object.

[michael-hamburg]

Why shouldn't I use simple value objects like "Money", "Currency" or
"Price" in the command? Using primitive types like "Integer" oder
"Double" in commands results in less type safety on the client side.
Therefore I prefer using more intelligent "strong types" (e.g. value
objects).

> On 22 Mrz., 19:21, Greg Young <gregoryyou...@gmail.com> wrote:
> I might make some structures in my messages assemby that get used by
> messages (or use types in xml etc) but never value objects from the domain
> model
>

[Greg Young]

Because they don't really exist on the other side. What happens after you use a bunch of them and then someone using python wants to send you commands/read your events? Those types may get "shared" when in a homogenous environment but won't exist for other environments.

[michael-hamburg]

That's why I try to generate those parts of an application. The model
definition of the command contains a value object (strong type). In a
homogenous environment it's also used when generating a command. For
other clients the base type is used instead. For me this is an
implementation detail. In the logical model it's always a value
object, no matter how it's generated later on.

On 25 Mrz., 10:03, Greg Young <gregoryyou...@gmail.com> wrote:
> Because they don't really exist on the other side. What happens after you
> use a bunch of them and then someone using python wants to send you
> commands/read your events? Those types may get "shared" when in a
> homogenous environment but won't exist for other environments.
>
> On Sun, Mar 25, 2012 at 3:50 AM, michael-hamburg <
>

[Greg Young]

It also means any change to a value object is a contract change. This cn be troublesome to manage.

[michael-hamburg]

That's right. I was thinking of pretty dumb value objects that are
more like specialized types (Money, Currency, UserName, ...) and only
contain one field (Integer, Double, String, ...) and no complex data
structures. I think those are rare to change. But of course it's a
good idea to think twice when including domain specific value objects
in a command.

[Thomas Oellrich]

Speaking of contracts, how do you guys document/specify contracts. The architects at my company are big fans of schema-validated XML, which makes versioning a PIA and forward/backward-compatibility practically impossible.

2012/3/25 Greg Young <gregor...@gmail.com>

[Greg Young]

Not at all so long as you version them.

[Thomas Oellrich]

But when you have one BC that publishes Events in a certain version and two other BC that listen to them and you create a new version by adding another field (i. e. keeping backward compatibility), wouldn't all BC need to upgrade at the same time and thereby being tightly coupled?

2012/3/25 Greg Young <gregor...@gmail.com>

[Greg Young]

What's you serialization format?

[Thomas Oellrich]

XML (schema validated)

2012/3/25 Greg Young <gregor...@gmail.com>

[Greg Young]

you can serialize with the rules that if you have something and its not present on version you try to serialize to then just say "ok". Beyond that host the xsds for validation (and of course version them with the messages).

You can get to the point that you dont need to upgrade them.

[michael-hamburg]

As Java developer I use Bean Validation (Annotations like @NotNull,
@Size, @Pattern, ..., Custom Validators) in the commands. This way
it's easy to validate an incoming command before it is handled in the
command handler. (Yes, I'm aware validation something that is part of
the domain logic - Command validation has only basic checks and domain
always validates too...). In a homogenous environment (in my case a
Java client) you can also use the same validation process to be sure
the command is valid before it's actually sent to the server. To avoid
problems with updates I always try to be backward compatible.

On Mar 25, 2:19 pm, Thomas Oellrich <toellr...@gmail.com> wrote:
> Speaking of contracts, how do you guys document/specify contracts. The
> architects at my company are big fans of schema-validated XML, which makes
> versioning a PIA and forward/backward-compatibility practically impossible.
>

> 2012/3/25 Greg Young <gregoryyou...@gmail.com>

[Thomas Oellrich]

Thanks, Greg and Micheal. Will look into this.

2012/3/25 Greg Young <gregor...@gmail.com>

[ashic]

K....so would ur [Json serilized] event look like this:

AccountDebitedEvent{

   accountId : 'laksjdajsldk',

   amount : 20000,

   currency: GBP,

   date: '2/2/2010'  //dumb string for simplicity here

}

or like this:

AccountDebitedEvent{

    accountId: 'asd',

    amount: {

        type:'money',
        amount: 20000,

        currency: GBP,

        date: '2/2/2010'

[michael-hamburg]

That's right. I think it's important to carefully think about how
stable such a value object is. As Greg said, you'll expose domain
functionality to the public. For simple types like
"UserName" (basically a string with restricted length & character set)
I don't see any problems with that. Structures like your "amount" VO
may be more problematic as there is a higher chance for a change.

> > value objects hidden from the command-issuer?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Michal Ge]

I know this is old post but what about Protocol Buffer specifications? It enables us to  specify commands/events at one place (language agnostic) and make them avaliable across different platforms. Doesn't this solve the problem?

[Clemens Vasters]

Only if you always know where your ProtoBuf specs are.

 

If you want to keep events around for a long time and want to go back to them, any risk of having the spec separated from the data or having the spec diverge from the data puts the entire store at risk of becoming illegible. Self-contained data structures are far better for this. If you want schematized and self-contained, consider Avro containers. This consideration here is why we use Avro for Event Hubs Capture archival.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.