Yeah, it’s definitely a trade-off. Walking through commands in the test does tend to reinforce the Ub. Language tho. One approach to take is a fluent fixture:

http://blog.eleutian.com/2007/09/29/FluentFixtures.aspx

That makes sense, but also leads to more complex setup for scenarios where the required state of the entity you want to test is the result of several commands performed on the entity.

I still expose setters for this very reason, but I feel dirty everytime I do it..

1) NHibernate deals with encapsulated collections and private setters very, very easily. Private setters don’t need any extra configuration. Encapsulated collections can be taken care of with Fluent NHibernate conventions. There really aren’t any hurdles there.

I haven’t done any event sourcing, but it definitely looks intriguing. I have a very difficult time projecting what that architecture would look like on the systems I develop.

2) How do I break encapsulation with persistence? No one outside my bounded context will have access to my persistence storage mechanism (DB or otherwise).

3) Probably not, LoD doesn’t really play a large part in my own domain modeling style.

And yeah, I can tag the posts

Nevertheless, I have some questions.
1) the first is about persistence. I see two options for now :
– classic ORM : setters are very useful for rehydration, even setters on collections…or you have to rely on introspection (like NHibernate do with private access).
– event sourcing that prone Greg Young with CQRS…but I haven’t dig enough to detail…
What is your position ?
2) The second is about an argument I often heard from pro anemic DM people : you say you encapsulate but you broke encapsulation with your persistence…I haven’t found a better answer than “I prefer business encapsulation than no encapsulation…and persistence is pure technical consideration, that’s why I allow breaking encapsulation…”
3) do you plan to talk about law of demeter ?

As an aside remark, could you tag all your series items with a special series tag, it would allow to make a link to the whole series (from delicious or blog for example…) ?

Thanks again.

It depends. If it’s a data-specific command, I tend to just leave the setters there. If it’s a behavioral command, I go the method route (although I still don’t have the object accept a command message, but go with explicit args).

I haven’t tried going command-only, so I’m not sure how that would work out in the long run.

In the type of CQRS which Greg Young is promoting the transactional database only stores a running compilation of the actual commands. I wonder for the “InvoiceRequest” objects how this would be handled. Maybe they would be stored in a CRUD manner in a “domain object staging” data store and then transition to the transactional data store once complete. I guess it depends upon whether or not it is important to preserve the history of the “XxxRequest” objects.

I’ve had situations like these, where in your example the user actually creates an “InvoiceRequest”. Eventually they can create a regular invoice from the invoice request, and it goes on from there. This helps especially if partial invoices aren’t invoices at all, and shouldn’t be treated as such.

For example, in an Accounts Payable application a user will need to enter an invoice. This involves filling out a whole bunch of fields, saving the invoice, and possibly editing some of these fields and saving again before some state change occurs which says that the invoice is now “processed” or “verified” or something like that.

Once the invoice has made it to this new state it becomes more behavioral. The user can void it and perform a handful of other operations on it. At this point the approach you’re recommending becomes applicable.

What am I missing? In my example would there be two domain objects: “invoice under construction” which is basically a CRUD getter/setter object and then it would become a “completed invoice” which would primarily have behavioral methods?

I’m sure that there is a solution for this, but in all the CQRS and other documents I’ve read it hasn’t been mentioned. What am I missing?

Typically, these pieces form commands that are then executed against the domain. It might take several to get to the finish line.

@k2

Yeah, np