Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
Domain Driven Design talk - 2/10/2009

 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

Posted 02-11-2009 9:42 AM by Anne Epstein



Ryan Svihla wrote re: Domain Driven Design talk - 2/10/2009
on 02-12-2009 12:09 AM

Anne thanks again for the talk.

I actually took your question about bounded context to heart and today took a slice out of that big legacy app and tried to move it towards a more DDD perspective.

I'm not sure how well it ended for pure DDD, but it certainly ended up moving MUCH closer to that direction than it ever had previously.

I'll probably focus on that area of the app for the near future so I can slowly make it a more complete Model.

Bobby Arnold wrote re: Domain Driven Design talk - 2/10/2009
on 03-31-2009 10:41 AM

I just finished the Evans book and stumbled onto your blog post here. I especially like your second point - a repository, it seems to me, ultimately provides high level organizing shape - "conceptual contour" if you will ;) - which ultimately reduces intellectual overhead. I'd love to see your DDD slides, but the link here  appears to be broken at the moment. Thanks!

custom website design wrote re: Domain Driven Design talk - 2/10/2009
on 12-21-2010 9:10 AM

Appreciating the time and effort you put into your blog and comprehensive information you provide! I’ll bookmark your weblog and have my children check up here frequently. Thumbs up!

crorkservice wrote re: Domain Driven Design talk - 2/10/2009
on 07-18-2014 1:41 PM

UQAa6E Major thanks for the blog article.Much thanks again. Will read on...

matt daemon wrote re: Domain Driven Design talk - 2/10/2009
on 03-09-2015 2:14 AM

gTCCtk There is apparently a bundle to know about this.  I consider you made some nice points in features also.

crorkz mattz wrote re: Domain Driven Design talk - 2/10/2009
on 04-07-2015 8:23 AM

hl4mQP Hello.This article was extremely fascinating, particularly because I was searching for thoughts on this topic last Wednesday.

mattew crorkzz wrote re: Domain Driven Design talk - 2/10/2009
on 04-08-2015 8:41 PM

g7h3Xu Keep working ,remarkable job!

crorkzz catz wrote re: Domain Driven Design talk - 2/10/2009
on 06-09-2015 4:37 AM

gECmBC Major thankies for the post.Thanks Again. Awesome.

best young pron wrote re: Domain Driven Design talk - 2/10/2009
on 10-14-2016 12:15 PM

oDEjaa I truly appreciate this post.Much thanks again. Great.

Add a Comment

Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)