I just read a post from fellow devlicio.us'er Billy McCafferty and was considering what influences my own solutions to these concerns (ie, repositories, data transfer, etc) now.
There has been an abrupt shift/growth in my thinking this year in how I perceive my domain and how I interact with or scale it. CQRS, perceived by some as a shiny new toy, and the discussions it provokes has definitely contributed to the maturity of the project I have been on by increasing its quality and adaptability. Why? My experience has been the simple shift to being concerned about what all these things are doing (behavioral mindset) instead of what they look like (stateful mindset). I now see that the decision to expose domain state at all should be one of the first decisions to make and its implications on the various infrastructural concerns should be well-understood. This seems to drive divers decisions both within the domain and how it is consumed or utilized without.
The first casualty of this shift was the getters and setters (whether exposed as properties or GetX()/SetX() methods). Hiding as much state as possible radically increases the freedom in the domain, especially when going down the event-sourcing route. As you know, the moment you expose a getter you now have a maintenance obligation. What I am discovering is that feels okay initially, but it very quickly acts as a Trojan Horse for forces outside the domain to act on its modeling. That innocent {get;} can make refactoring far more difficult that it needs to be, if only the decision were made earlier to Report state from somewhere other than the domain.
IMHO, this is true for a “small” application, although I am not sure I believe in “small” applications anymore. They all seem to be getting feature-creep hormones from somewhere :).
Posted
03-06-2010 10:45 PM
by
Michael Nichols