I've been reading about Domain Driven Design for almost two years and have been cautiously been introducing some concepts in to my daily work or at least making plans for how things I do regularly could be done within a Domain Driven Design.
One conclusion that I've beginning to come to especially in response to reading more about Event Sourcing and Command Query Responsibility Segregation (CQRS) that perhaps domain objects are intended to be used only for write purposes. To be more clear, it seems that what people are subtly suggesting in much of the documentation I've read that the domain objects are responsible for doing domain centric operations/calculations, validation, and then are there mainly to provide a road to persistence through the infrastructure provided within a Repository implementation. Although I do like the fact that this may simplifies the domain model greatly as it cuts out the responsibility of exposing state.
If it is indeed correct that domain objects are mainly to be used as write-only objects then that raises some questions for me that I'm hoping somebody could answer.
- How does one perform unit tests on an object that has setters, or methods that modify the state of an object but that provide no outwardly public interface to read the state from such as property getters in C#? Is it okay to expose state solely for the purpose of making that object testable?
- How does one show to a user the results of calculations or operations done in the domain without having to persist them and then pull the results from persist store outside of the context of the domain? Is it okay to expose state solely for the purpose of showing results.
Is the rule of thumb that the only property getters (get accessors) should be ones that are also writable in the domain? Or said differently should readonly properties be the only thing to avoid since they are only there for read purposes and thus do not play a a necessary role in the actual domain model?