I did an introductory DDD talk at the Alamo Coders meeting in San Antonio yesterday. There were a number of excellent questions asked-two that I wanted to get in writing were:
- "I have a pretty big legacy app, done in a pretty procedural way... what can I do to migrate this app in the direction of DDD?" - I've thought about this, and I believe one of the better ways to deal with this is to really embrace the idea of bounded context. Don't try to migrate the entire application, layer by layer, bottom to top. That would be an extremely disruptive effort, and one that may not see payoff until a huge amount of conversion work has been invested. Instead, really think about the app, work on what the models in the system are, and look for features or areas of the application that can be pulled apart-in particular, look for things that can end up being bounded contexts... work on improving the application in vertical slices within a bounded context, or if that's too big, within a module, or even within an aggregate root. The less coupled with the rest of the application the section you can pull out is, the less connection you have to do to make it work with the existing code. It allows you do do your migration in smaller, more managable chunks, and it gets you payoff quickly.
- "Separating things like a repository out into separate layers seems like it would be adding more complexity, not taking it away. Now you have more stuff to worry about. How is this really an improvement?" - I think this is a really common concern. When setting up an application with DDD in mind, which really overlaps with the SOLID principles, you may indeed end up with more pieces, which is adding a bit of extra complexity-and sure, you could argue that all this kind of setup is really doing is moving pieces around. The real contribution here is that when you design without these principles and need to understand how something works, you'll look at a section, see it's fundamentally tied in to other pieces, and need to end up understanding all the things it's tied to to understand your one piece. When designing in a more separated fashion, looking at the one piece you're concerned with will tell you all you need to know. All that additional complexity in those other components is still present, but you don't have to worry about it unless that's what you're looking at. So, though the amount of complexity present across the entire system may be the same, the amount of complexity you have to worry about at any one time drops, ad you feel less complexity.
My presentation slides might not be that meaningful without the talk, but here they are...
Domain Driven Design
02-11-2009 9:42 AM