Modified Command Pattern

There's some support for a sort of split Command Pattern where the data lives in one object called the "Command" while the behavior resides explicitly in another object e.g. "handler" or implicitly as in the case of Spring MVC (see example code).

As mentioned it appears in Spring MVC and more recently adopted by CQRS developers.

see http://stackoverflow.com/questions/6617976/dependency-injection-when-using-the-command-pattern and https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91

It has benefits for testing because the runtime data is separated from the compile time behavior. This separation is discussed  in the context of dependency injection by Misko Hevery.

I wonder though what OO proponents like Martin Fowler would say to this; i.e. would they deem the artifacts, the commands, to make up an anemic domain model?

On the other hand, according to some the trend seems to be toward separating behavior from objects in certain respects. E.g. I recall Coplien (of DCI) saying "good objects are dumb" implying albeit that the behavior can be injected at runtime. So maybe that's not the best example. But here's a quote from 'User' on Stackoverflow for what it's worth. It's on the example of where should 'validate()' go:

I think in the past CreditCard.Validate() would have been considered good object oriented design but the trend seems to be away from that towards many separate classes.

http://stackoverflow.com/questions/3117800/dependency-injection-when-the-class-created-also-needs-runtime-values

However, Ayende Rahien asserts the opposite is (or should be) taking place (i.e. to move toward putting data and behavior back together?): http://ayende.com/blog/4503/component-oriented-design-and-why-it-be-retired

Notes
The author of this Command/Handler pattern also demonstrated the Query/Handler analog which is extremely telling and revolutionary with regard to deconstructing the Repository pattern as it's commonly implemented: https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92

CQRS and Architecture

lecture from several years ago. Items of interest are  

• an architecture graphic from 48:57 picturing both validation and business rules as components as opposed to layers
• the idea that a database ("persistent viewmodel") with viewmodel tables should replace the in-memory caches
• capturing the user's intent is not necessarily the same as editing a row in the database: "The fact that they are two columns on the same entity does not mean anything!"
• Example of user's intent is "reserve a block of seats on airplane for family/friends" but UI given is seats with checkboxes and a refresh button (to see what's changed to allow what they want)
• What are domain models for?
• "Domain models aren't for validation." Validation is there in its own component"
• see graphic from 48:57 and 1:29:38 where domain model is the "Rules" component
• validation component is actually the same one on the client-side and server-side (see graphic)
• Domain models aren't for queries.
• Domain models are for business rules: e.g. figuring out how much interest to charge once the user has violated terms of agreement and over-withdrawn their account despite the best-efforts of the client-side validation logic.
• Domain models are for doing what business people spend time on -- thinking of "adding weird ways to add functionality to the system to delight their customers" e.g. is it their birthday, should I send them a birthday present, is he a preferred customer, etc.
• "Client-side controllers [that are using the CQRS queries] are supposed to do [business] logic. It's not that big a deal"
• Quote on commands, that they must go through asynchronous messaging pipeline: "You need to design your commands such that you can say 'Thank you. Your email confirmation will arrive shortly."
• On Relationships
• "Once you've taken out all the relationships from your domain models they've actually become smaller and tighter -- focused really just on processing commands"
• And DTOs, ORM, etc. is removed from the query procesing and replaced with the one-table per view ViewModel (note points on search recommendations and removing ability to do complex queries from the user)

Quotes:
"Writing a custom form to accept: how many seats do you want? What kind of seats do you want? Trivial forms to write. Writing these query screens, now that you don't have to go through DTOs and domain models and object-relational mappers, and god-knows what else -- these are a lot of easier to write too! Once you've taken all these relationships from your domain models, they've also become quite a bit smaller and tighter focused really just on processing commands.

"Yes you do need to understand what your users are using the system for. Otherwise just give them access to your database and be done with it. "

"You can't shoehorn a CQRS architecture underneath an editable datagrid. Do not try. User interface design is as much a part of architecture as anything else that you do."

https://skillsmatter.com/skillscasts/1250-udi-dahan-command-query-responsibility-segregation#video

Project Server

Microsoft's Project Server appears to be a good example of a combination of BLL/DAL and CQRS. See http://msdn.microsoft.com/en-us/library/office/ee767687.aspx

Event Sourcing

"If you are using a structural model right now you are losing information"

Greg Young http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing/

Domain Objects

Out Domain Objects are purely behavioral. ... You will never, ever, ever have a setter on any of your domain objects. Domain Objects are not property buckets.

Gren Young http://skillsmatter.com/podcast/design-architecture/architectural-innovation-eventing-event-sourcing/

CQRS

In regular client-server development, the server is responsible for providing the client with all CRUD (create, read, update, and delete) capabilities. However, when users look at data they do not often require it to be up to date to the second (given that they often look at the same screen for several seconds to minutes at a time). As such, retrieving data from the same table as that being used for highly consistent transaction processing creates contention resulting in poor performance for all CRUD actions under higher load.

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

Querying: - Have a look to Users, what are they really interested in? - It's not searching, it's finding; - It's not refreshing, it's looking for events

 Alberto Brandolini - http://vimeo.com/16054927 - 41:10