September 2004 - Posts
I was glad to see Steve's "
Refactoring Our Way to Glory: An exercise in implementing a domain-driven design" post. It not only addressed some concerns that I had with the event based solution that
Udi presented but it also introduced a lot of other concepts that are extremely valuable. I have some thoughts of my own on the topic that I'm hoping I'll get a chance to blog shortly. For the time being get your fill from Steve Maine's solution.
I came across a post by Martin Fowler on
DecoratedCommand. It's amazing the power that a simpler decorator can add to an object model. By creating a TransactionalCommand and a SecurityDecorator to a domain model that is using
CommandOrientedInterfaces Martin shows how a set of fairly simple commands can be expanded to provide additional functionality. The solution is AOP'ish (aspect oriented programming). The thing I love about it is the simplicity of the design. Its amazing what too much thought can do to a design. Keep it simple.
There has been a
lot of
talk recently about ReSharper. When I tried it out several months ago I really loved it, BUT, the performance was so bad I had to do the unthinkable and uninstall it. Brendan has assured me performance is much improved so I'm going to take it for a test spin and see how it goes. I'd be very surprised if JetBrains didn't have my $99 by weeks end.
I spent a bunch of time trying to track a problem down which ended up being due to
the "limitation" Scott mentions. All those using the FormsAuthentication.UserData property beware.
Udi Dahan has a post on DDD which builds upon some examples discussed in my Repositories and Factories post (and comments). Udi doesn't get too deep into his opinions on the topic but he does offer a glimpse.
For those interested in how save can take place in the example "repository.Save(customer);" when the customer has an address, the answer is to use events. (This is beginning to reflect my views on the subject). The question was how do we keep the customer repository from knowing about how to save addresses, and, more so, from knowing about the address repository. As a part of saving the customer, the customer repository calls the Save method on the address property. This is OK because the customer repository knows about the structure of the customer and knows that it has an address that requires saving. But, that's as far as its knowledge goes. The beauty of this solution is that the address object's Save method does nothing but raise an event. The address repository subscribed to this event when it reconstituted the address object, and can now handle the saving without any ties to the customer object, its repository, or anything else.
I'll be very interested to see where Udi goes with the example he provides. The idea of using events to ensure that the domain objects don't know anything about their repository is an interesting one. The topic is one that I don't think Eric Evans covers that well in DDD. He discusses a lot of theory and principles but doesn't talk much about how to go about implementing those principles. It's nice to see someone (Udi) step up to the plate and give it a shot.
The one other method that I've seen people advocate for ensuring the domain objects aren't coupled to their repositories is dependency injection. The Address object would know it had a repository but wouldn't be coupled to any one particular repository. The route that Udi is taking does that method one better by removing the coupling between the address object and it's repository completely.
The other topic which I think needs to be considered with the examples we're talking about is aggregates. Within DDD we hear a lot about aggregates. An aggregate is a grouping of related classes. The grouping of related classes has a root object through which all other classes are accessed. In our example Customer could be the root of the aggregate through which other objects in the aggregate are accessed (Address, Order, etc.). Since the creation of aggregates is extremely dependent on the domain it's tough to talk in too much detail about whether or not this particular "aggregate" would appear in a domain model, but it does impact the discussion a bit. DDD advocates the creation of a repository per aggregate. So if in our domain the address is part of the customer aggregate, according to DDD, our repository would be the same for both the customer and the address. In reality this probably isn't that likely, however, I thought I'd bring it up so future posts can expand upon the concept a bit.
Many more thoughts to come...
Paul Wilson posted a
great rant on why he believes in O/R Mapping. All I can say is I'm in 100% agreement with Paul. I know there are lots of people out there who don't believe in O/R Mapping, but I'm certainly not one of them. I think one of the problems people have with O/R Mappers is they try and make them work for every circumstance. Just like everything else that we have in our toolkit, O/R Mappers have a time and place. Their are times when forcing your application to use an O/R Mapper is NOT the way to go. When you look at the breakdown with what is involved with building an application that uses a O/R Mapper and one that does not it's clear what is the better choice. O/R Mappers are not a silver bullet, but they do kick ass
Matts Helander has a great post about how the red, yes red, not green provides the real value when unit testing.
It's the Exceptions, Stupid
It's funny how life works. Just today I was updating an application, writing unit tests, and ended up being marveled by the red. I made a very small code update that seemed to be very isolated and very safe. Just for the heck of it I fired up NUnit and ran my suite of tests. Much to my surprise I saw a whole lot of Red. It turned out I had underestimated the impact of the "small" change. It in fact impacted several other components. Thankfully I had NUnit to get me back in line.
As a funny aside after reading Matts posts I went to fire up BlogJet to write this post but "accidentally" clicked on NUnit. I think I was hoping I might be able to run NUnit to catch any errors I wrote while writing this post. I think that feature is coming in 2.3 ;-)
Anyone who's been reading this blog for a while may know that I've always been a proponent of what I used to call a "rich Domain Model". To get a feel for what I was referring to when I talked about a Domain Model check out the following posts:
Domain Driven Design has caused me to put some further thought into the topic. I've always wanted everything wrapped up in my domain objects. Rather then dealing with managers and domain objects and trying to decide what belongs where I always liked having everything packaged up in a nice rich domain model. I was so attached to this approach that even after reading through DDD I was still in this camp. It took a couple email's to the DDD mailing list for me to realize I had made the chapters in DDD say what I wanted, I made them read as if what I was doing was what was recommended. This caused me to go back and re-read many of the chapters in DDD which helped me realize that the recommendations that were being made were much more in line with what I had called the Manager model in the past.
Fortunetly for me I don't totally distort everything that was said in the chapters. DDD does advocate a rich domain model, just not the type of rich domain model I had been using.
Before reading DDD my domain objects had the following responsibilities:
- Used DAL layer to retrieve items from the data store
- Had deep relationships with other objects in the model.
- Contained domain logic relevant the the real world object being represented by the domain object
- Were used to retrieve single instances as well as collections of domain objects
After reading DDD my domain objects become a little simpler and give up much of their responsibility. Rather then concerning themselves with multiple responsibilities the role of the domain object (Entity) is simply to model the real world object's data and behavior. Some of the responsibility previously contained in my "rich domain model" has been moved out to Repositories. Repositories take on the responsibility of returning objects from a data store. They handle returning single instances of objects as well as collections of objects. To ensure the repositories don't start taking on too much responsibility we introduce Factories. Factories take data retrieved and turn them into actual domain objects. Often times we have a coupling between our Repository and a Factory. To ensure the two are loosely coupled I recommend the Factoring be configured using Dependency Injection. This allows any Factory to be "inserted" into the repository and ensures that none of our objects are coupled to one another.
As you may be able to see, my view on the wonderful world of domains has changed pretty significantly. By moving much of the responsibility out of the domains and into other objects that can better handle the responsibility we're able to creating more flexible domain models. Rather then gradually creating gigantic domain objects with all kinds of dependencies and way too much responsibility we create a set of components that make up our rich domain model.
It's been a while since I've picked up any new books and in an effort to start back up on the "self learning" I've purchased the following books:
Enterprise Integration Patterns - Read the intro as well as the first chapter. I'm going to really dig this book. It's amazing how as you start reading about new things you start seeing all the areas in which they could/should be used. Looking forward to learning from some of the Thoughtworkers, where do they find all the smart dudes?
Mono Developers Notebook - For those of you who don't know I purchased a PowerMac G4 recently. Partly because I want to do some more non MS development, partly because I want to play with Mono, and partly because I really dig the photo and video software that Apple puts out.
Hibernate Developers Notebook - I'm a O/R Mapping nut. I love working on them, reading about them, and checking out the source for implementations of them. You can learn so much working on one, and they pose many interesting challenges that "typical business applications" just don't make you think about.
Well I've been struggling to get much of anything go of interest up on this blog recently so I'm going to try and re-focus on writing something interesting to people besides those 3 dudes that still don't have gmail invites. Some of the things I'm hoping to rant on are:
- Domain Driven Design and how it's changing my view on how I develop software...at least I think
- Enterprise Integration Patterns - I'm reading the book so I'm bound to have some thoughts on what's presented. Oh, and has Thoughtworks opened their Philly office yet....didn't think so
- A .NET "dude" on a J2EE wannabe project
- Going Independent Aspirations or Not?
- Architect vs. Tech Lead, which is better and why?
And who the heck knows what else. All I know is the gmail posts are no more (although I do have invites if anyone wants em)
Cheers,
Steve
This past week I've had to re-visit some code that I originally wrote when I was first learning .NET. At the time I was writing the application I felt pretty good about the "architecture" I was using. I really thought I knew my stuff. As I look back on the results of my efforts many moons ago I can only laugh at how little I knew. It's amazing how much one can move within a couple years. Experience and a dedication to continuous learning can do wonders even for those who think they know what they're doing. I wonder if in another three years I'll look back at the code I write today and get the same chuckle. The funny thing is the more I learn the more I realize how much I don't know. I'm looking forward to the end of this tidal wave of work I'm in the middle of so I can get back to learning new things so I can indeed laugh at my self three years from today.
Just came across the Cocoa# wiki for any folks out there interesting in Mono development on MacOS X.
http://www.lormyr.com/cocoaSharp/default.aspx/CocoaSharp.CocoaSharp
It sure would be cool if Apple fully embraced .NET as it has Java and integrated it into their XCode development tools. Speaking of which if your interesting in C# project templates for XCode check out: http://www.druware.com/products/xcodetools.html.