The Biggest Driver For Domain Modeling Decisions

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

[Advertisement]

Comments

Billy McCafferty wrote re: The Biggest Driver For Domain Modeling Decisions
on 03-09-2010 11:49 AM

Great points Mike.  Although it's hard to find small applications anymore, as you mentioned tongue in cheek, I do think that expected application size should have an immense bearing on the architectural decisions of an application.  For example, I did a couple of small eCommerce stores a couple years back and the use of Active Record with little separation of concerns was a terrific way to get the application up and running very quickly.  With a more recent project, which turned into an enormous CRUD application which tons of reporting needs, using S#arp Q3 "out of the box" wasn't enough to keep the controllers layer easily maintainable and the reports performant.  In hind sight, if we had leveraged application services more appropriately, keeping the controllers very clean of workflow logic, and employed CQS more for reporting needs, the application would have been simpler to maintain with much better performance.

Changing gears slightly, it's funny how often people put down most new and emerging ideas as being faddish or those-which-came-from-developers-with-too-much-time-on-their-hands.  When it comes down to it, new ideas are (hopefully) generated in response to a need or challenge.  CQS is simply naming a good idea which has been used frequently in the past, allowing it now be more effectively and concisely communicated to others who may be facing similar problems.  With that said, there are certainly ideas which do not solve problems as well as others; it's our job as a community to discuss these ideas, exactly as we're doing here, to allow natural selection to take due course to have the best ideas survive.  (Obviously, a corporation like Microsoft with millions of dollars to back specific ideas can usurp natural selection of ideas generated via group-think, but they still come up with something pretty good now and then. ;)  The trick is figuring out which ideas are worth keeping around without experiencing too much pain in the process. ;)

Along these lines, there's a great book about the evolution of ideas called "The Meme Machine" by Susan Blackmore.  After reading it, it makes the blogosphere much more interested to observe.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)