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

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/

TS/ADM vs. DM

One of the key benefits of a domain model approach is that it hides the complexity of the different components behind the core objects of the problem domain. I like to think that in a transaction script model, the locus of control is placed outside of your core objects. In a well designed domain model, the locus of control is contained within your core objects (even if big pieces of functionality are still implemented in external services).

http://charliedigital.com/2009/07/29/domain-models-anemic-domain-models-and-transaction-scripts-oh-my/

Extension Methods

In my last project, I used extension method to attach Validate() methods to business objects. I justified this because the business objects where serializable data transfer objects and will be used in diffrent domains as they where general ecommerce entities such as product, customer, merchant etc. Well in diffrent domains the business rules may be diffrent as well so I encapsulated my late bound validation logic in a Validate method attahced to the base class of my data transfer objects.

Athens - http://stackoverflow.com/questions/487904/what-advantages-of-extension-methods-have-you-found

Domain Services

Domain services are the coordinators, allowing higher level functionality between many different smaller parts.  These would include things like OrderProcessor, ProductFinder, FundsTransferService, and so on.  Since Domain Services are first-class citizens of our domain model, their names and usages should be part of the Ubiquitous Language.  Meanings and responsibilities should make sense to the stakeholders or domain experts.

 http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

Transaction Script = ADM?

It would seem that your project might be suffering the side effects of an anemic domain model. As I have observed that these models tend to be used mostly with a transaction script style design, I will use these two terms interchangeably.

 http://charliedigital.com/2009/07/29/domain-models-anemic-domain-models-and-transaction-scripts-oh-my/

What I’ve achieved by applying the DDD patterns is the elimination of those transaction scripts and (most) services. The transaction script (e.g. struts action in a web application if you’re so inclined) is simply responsible for finding an appropriate entry-point into the domain, then telling that domain class to do some work.

 http://evan.bottch.com/2007/12/06/factory-and-repository-in-the-domain/

Domain Logic

[The Anemic Domain Model] [n]ecessitates a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).

http://en.wikipedia.org/wiki/Anemic_Domain_Model

but...

[Some are] just technical constraints, according to Dahan: “The business doesn’t care that username fields are 8 characters. Usernames have to be unique for technical reasons to be able to select customers to check details”. Rules that are not part of genuine domain logic do not have to be implemented in the domain model, suggested he, because they do not model the domain. They may be deployed to a separate tier.

http://agile.dzone.com/news/biggest-mistakes-teams-make

Udi again:

Validation of string lengths, data ranges, etc is not domain logic and is best handled elsewhere (and a topic for a different post). The same goes for uniqueness.

http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/

Application or Domain?

An additional question you could ask is: if, in the future, I need to build another application on top of this domain model (e.g. a web service or a rich client), would I still need to deal with the concept of a Channel? 

Mark Seemann - http://stackoverflow.com/questions/1425749/anaemic-domain-models-or-where-to-put-logic

Domain Entities

Main concern of entities should be keeping track of business state - that's enough of a responsibility and they shouldn't be concerned with validation. ...

[W]hether an entity is "valid" depends on its state and its context. George Polevoy points this out nicely in his answer and I share his opinion.

 Marijn - http://stackoverflow.com/questions/5818898/where-to-put-global-rules-validation-in-ddd

The above appears to contrast with the following advice:

Also your example seems to imply that your object can exist in an invalid state, this should be avoided, your domain object should always be in a valid state.

Kdeveloper - http://programmers.stackexchange.com/questions/70734/ddd-a-rookies-unanswered-questions

Oder is both a noun and a verb. The "Order" is the object that created as a result of "Ordering". Like any good class, it has both data and behavior (and I don't mean getters and setters). The behavior is the dynamic process that goes with the data, i.e., the ordering workflow. "Order" is the controller.

Doug Knesek -  http://stackoverflow.com/questions/1468218/domain-driven-design-where-does-the-workflow-logic-lie

 When a domain object begins to contain too many responsibilities, we start to break out those extra responsibilities into things like value objects and domain services.

 http://lostechies.com/jimmybogard/2010/03/30/strengthening-your-domain-the-double-dispatch-pattern/

Persistence Ignorance

Your questions and doubts ring an interesting alarm here, I think you went a bit too far in your interpretation of a "rich domain model". Richness doesn't go as far as implying that persistence logic must be handled by the domain objects, in other words, no, they shouldn't know how to save and delete themselves (at least not explicitely, though Hibernate actually adds some persistence logic transparently). This is often referred to as persistence ignorance.
I suggest that you keep the existing DAO injection system (a nice thing to have for unit testing) and leave the persistence layer as is while trying to move some business logic to your entities where it's fit. A good starting point to do that is to identify Aggregates and establish your Aggregate Roots. They'll often contain more business logic than the other entities.
However, this is not to say domain objects should contain all logic (especially not logic needed by many other objects across the application, which often belongs in Services).

 ian31 - http://stackoverflow.com/questions/4708689/ddd-where-to-put-persistence-logic-and-when-to-use-orm-mapping

Domain Model vs. BLL

Just to be clear, I like to think of a Business Model and Business Logic as two separate layers. Your business model are your POCOs (Plain old CLR objects). Your business logic layer would be responsible for performing validations, transactions, etc using both your business model and an interface to your DAL that could be wired up a number of ways (Spring, Castle, or your own home grown IoC container).

Trent -  http://www.techques.com/question/1-458098/Business-Logic-Layer-and-Data-Access-layer:-circular-dependency

I'd like to remove the coupling to allow us to support different address repositories as we can with the .Save within our CustomerRepository (via RepositoryFactory). I'd also like to remove any knowledge of repositories from my domain objects. Although it isn't always possible I prefer for application code to have knowledge of repositories NOT my domain objects.

 http://web.archive.org/web/20100420152400/http://steve.emxsoftware.com/Domain%20Driven%20Design/DDD%20Reconstituting%20objects%20from%20multiple%20Repositories

Domain Model

A domain model can be seen as an interface or a pipe between the Requirement Engineering phase and the Design Phase of the software development life cycle.

http://www.site.uottawa.ca/~ssome/UCEdWeb/publis/domainGen.pdf

Rule of thumb: If you are passing around primitive data types among object collaborators, it may be an indication you are not communicating at the right level of abstraction. You need to see whether the primitive data types represent concepts in your domain that you may have missed. 

 http://msdn.microsoft.com/en-us/magazine/dd882516.aspx

Let’s begin by using slightly different names. Let’s call the model of data that you persist the domain model and call the data you manage in the view the view model. I should mention that domain model isn’t exactly a neutral term in software, as it refers to an object model designed according to a number of additional rules. In the scope of this article, I’m not using the meaning that results from the Domain-Driven Design (DDD) methodology. For me, here, the domain model is simply the object model you persist—entity model might be another equivalent—and less confusing—term.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

I'll just add that at the heart of the application, there isn't necessarily *a* Domain Model, but possible *some* Domain Models.
The same application can have several aspects, or contexts, that might be modelled differently.
the cool stuff - all aspects might share the same storage mechanism (i.e. RDBMS tables), and it would fit perfectly in the Domain-driven Onion modelling of the system

 Ken Egozi - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

GUI will ask Repository to get domain object by id.. and once GUI has the domain object you could navigate it to reach other objects.. This way Domain layer does not need to know anything about repositories..

 StackUnderflow - http://www.techques.com/question/1-458098/Business-Logic-Layer-and-Data-Access-layer:-circular-dependency see also on idea of splitting BLL into Service/Business Logic Layer and Domain Model Layer

• We'll have a richer domain model which contains state, relationships, and logic inherent to the objects in that domain model.
   http://stackoverflow.com/questions/4708689/ddd-where-to-put-persistence-logic-and-when-to-use-orm-mapping

The Domain Model is a self-contained component – it doesn’t take dependencies on anything else. What it does is raise events that external code can use to make decisions about which external “service” to call.

http://www.udidahan.com/2008/02/15/from-crud-to-domain-driven-fluency/

The definition fat model means having as many domain objects as needed. Be it reports, validators, filters, entities, strategies and so on.

http://www.thedeveloperday.com/skinny-controllers/