Thanks for the response.

Having the Q’s data on the same OLTP database simplifies the solution a lot. I got it. Actually you answered my next question too ;o)

Thanks,
Mehdi

Often the effort is much smaller than it may appear, as we are solving two smaller, more specific problems than one larger, more generic one.

There is also a gradient to how independent you keep the pieces. You could choose to implement Q of CQS over the same DB as the C part, thus having it automatically in sync. Just knowing that you can implement the Q part using different patterns often simplifies its code.

Hope that makes sense.

Thanks for the response. I had already read that excellent article, and your answer does help.

I am just a bit concerned about the extra efforts involved. Please kindly correct me if I am wrong:
If the query database in your CQS article gets implemented as an OLAP database, then it has to be always in sync with the OLTP database (well, with a few seconds delay); otherwise Queries (in CQS) and Reports will not show proper data. That means there will be two live databases (instead of one) to implement and maintain. That said, I think this model suits large scale enterprise applications which anyway need that kind of effort (right?!).

Thanks a lot for your helps.

Regards,
Mehdi

Take a look at this post for some background:

http://www.udidahan.com/2008/08/11/command-query-separation-and-soa/

In short, when a our domain model performs the logic making a customer a gold customer, it publishes that fact. The reporting system takes that fact (the status of customer 7 is gold) and stores it as is, likely in a different (denormalized) schema than the one used under the domain model.

Does that help?

David asked a question above: How do you generate reports based on data that depends on application/business logic (i.e. up in object world, above the ORM layer)?

I read your answer but it was not quite clear for me! For example, in a system where Gold Customer is defined by some specification over domain model, I am not quite sure how to create a report of Gold Customers without repeating this specification on my reporting server.

Regards,
Mehdi

Thanks for your response. I think I found a podcast of yours that talks about this.

I do not know how I had missed your blog before. I (every architect/developer) should spend some time reading through it. You may see more questions from me; please kindly be patient with me.

Regards,
Mehdi

Glad you liked those articles. You may find some answers to your questions under my smart client and DDD categories:

http://www.udidahan.com/category/smart-client/

http://www.udidahan.com/category/ddd/

Let me know if you have any questions that aren’t addressed by all that content

Nice idea with the @deprecated – I like it.
The interface is not only designed to prevent access to the setters but to all you to be explicit about the use case in which an object will be used.

In other words, you could have multiple interfaces implemented by the same class where each calls out a specific use case.

Nice post here. As a principle I tend to discourage the use of setters, but I do not always impose an interface on top, to prevent accessing the setters. However setters are meant to be used by frameworks, not by humans, so my trick is often to mark them as @deprecated (which is a reasonable trade-off solution in java).

If things get tougher, like in your answer to Colin, I couldn’t agree more. Also on points 1 and 3, of course…

Best regards

Alberto

Sorry get you now and yeah couldn’t agree more. Definitely wouldn’t trigger that sort of behavior from a property, I was just thinking of at most putting that address value object into the appropriate temporal collection.

If I did have that sort of behavior then absolutely I agree methods are the way to go, and if its cross aggregate maybe even a service.

“Does that make sense?”

As always it makes perfect sense and ta for replying.

It all depends on your domain, but I’d say that as rules get added around that change of address that the setter becomes less suitable.

For instance, if we start correlating address to income brackets and make additional changes to the domain objects as a result of that change, or if we use that information for proximity calculations for preferred shipping partners.

Also, we need to understand that the ORM will be using that setter to fill the object with data, in which case we won’t want to do all sorts of validation or business logic, leading us to map to private fields, a no-no in terms of maintainability.

So, while it may “work” in many cases, using a method is the preferred option. Keep in mind that putting a DTO/message on top of the method, while compatible, is not necessary.

Does that make sense?

On the change address without setters example, let’s say Address is a value object and we do this:

customer.CurrentAddress = address;

Is this not an equally viable solution for many cases?

Also I’m not recommending any automatic binding to the domain or saying this is the right way to do things in all cases but equally I’m just not sure that always creating a DTO/message and a method always makes sense.

This approach is very interesting and I think the same as Ayende was recommending to me on the NHibernate users group. Do you have a small example project where point 2 can be seen in action?

Thanks

Sean

“Real-time visibility” needs to be handled with some kind of publish/subscribe infrastructure otherwise users have to keep refreshing their screen. Object relational mapping makes no difference either way to that requirement.

Once multiple users / multiple event sources can update the same data, more powerful solutions are needed.

Reporting is done by having your OLTP system publish events about things it has changed (using the domain model), and your reporting (OLAP) system subscribing to those events, and writing the data to whatever structure is most suitable for it.

The question was not at all ignorant.

Reporting is handled in such a way that it has no impact at all on the domain model.

That’s correct – UI code doesn’t use classes from the domain model for capturing data entered by the user. You may have a presentation model whose classes are designed for that.

Messages are used to communicate the change. While messages are data transfer objects, they do not represent the entities so much as what needs to happen to those entities. Not Customer, Order, etc – rather ChangeCustomerAddress, CancelOrder, etc.

In that sense, you’re not doing a “vanilla update” of the entities in the domain model, but calling domain-specific methods on them:

using (ISession session = GetSession())
using (ITransaction tx = session.BeginTransaction())
{
Address a = Convert.From<AddressDTO>.To<Address>(message.Address);
Customer c = session.Get<Customer>(message.CustomerId);

c.ChangeAddress(a);
tx.Commit();
}

How would you satisfy the requirement of the “real-time visibility” when requirement says: “I want report that shows on-hand inventory at the moment when I pressed [Quantity on Hand] button” ?

Apologies in advance for the ignorant question …

How do you generate reports based on data that depends on application/business logic (i.e. up in object world, above the ORM layer)? Is it just a matter of pulling the relevant data from an app/service interface into a reporting DB?

Regards,
David