Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Firstly, no, domain objects should never exist in an invalid state.</p> <p>I think the confusion you are having stems from the fact you are trying to power your UI screens from domain objects (and you are definitely not the only one), i.e. binding to your domain objects properties. You shouldn't. Your UI should get it's data from the properties of a view model; a purpose built UI object, which is allowed to be in an invalid state, and can make use of any cool UI validation frameworks. </p> <p>Domain objects should only come into play in the context of a command/transaction. i.e. the user has selected a view model object from a list on the screen and wishes to perform an action on it. Typically the UI will then call an application/command service method for the action they wish to perform, passing the ID from the view model the user has selected. This will then retrieve the domain object from it's repository and invoke the appropriate method.</p> <p>In terms of where the view model object comes from: I have a separate query service that the UI calls. This provides 'flat' (de-normalised aggregated data) DTO's which can be used to populate view model objects or act as the view models themselves. This service is unaware of any domain model and simply returns projections from the data that the domain objects conduct transactions over.</p> <p>I can't recommend enough reading up on <a href="http://martinfowler.com/bliki/CQRS.html" rel="nofollow">CQRS</a>, even if you only take up certain aspects of it. Not only does it help make <strong>practical</strong> sense of DDD, but if implemented well it can really help with the performance aspect of getting the data to your UI screens.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload