Wednesday, December 10, 2008

DDD Confusion

this is mainly in comment about this post:

My points:
  • DDD is not needed in every situation.
  • DDD is used when there is a significant amount of business logic. If you are writing crud screens DDD is probably not the best option.
  • DDD is hugely beneficial in an Enterprise Solution. This is because there is business logic in business applications.
  • DDD is not hard, if done right. Start simple and add complexity AS REQUIRED.
  • DDD scales. I have a base framework that I use for DDD solutions which let me get up and running with in a few minutes. I still have to write the domain objects, but if these are simple objects this takes a trivial amount of time, but still leaves me open to scaling to a large solution if and when it is necessary.
Like most architectures the majority of people get a wiff of it and run with the idea without properly implementing it. This is when you run in to problems.
Of the last 5 web applications I have done DDD was involved in only 1 of them. The other 4 took less than a week to complete.
Here is something a little more concrete: I would use my NH based DDD stack for anything I thought would take more than 2 weeks of dev time to complete.
Like anything the more you do it the more you learn, you pick up good ideas and recognise bad ones. The problem with DDD is you cant just read the book and know it you have to go thru the pain of doing whole projects to get that knowledge.

No comments: