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 imagehelp@codebetter.com
DDD: What Kind of Applications Is It Suited To?

In many conversations, and in many comments here, you hear phrases like “well that’s not really suited to DDD” or “DDD isn’t the best fit for that problem”. You even see those kind of comments on my blog, and often they are posted by me.

This obviously leaves a number of people confused, after all DDD is the wonder cure for every software illness, surely there is nothing it cannot do!!!!

Download the eBook of the Series so far …

Where is Domain Driven Design a Good Fit?

DDD is a software methodology suited to a particular kind of application – one where there is significant complexity, and there is a significant focus on a well defined business model.

Complexity

cubeThe subtitle of Eric Evans book says it all - “Tackling Complexity in the Heart of Software” – DDD is a way of making complex systems more manageable, better understanding their intricacies, and simplifying a subject that could otherwise be overwhelming – i.e. avoiding a classic big ball of mud.

We often end up with a Big Ball of Mud when we started out with a fairly sketchy idea of the requirements we had, and built our software in such a way that rigidity set in early on. Over time as new requirements evolve, we bolt them on to what we had before, and piece by piece we end up with our Mud Ball … or as I like to imagine it – a Borg Cube – where all your code has been assimilated, and is now part of the collective.

By applying DDD we can break that complexity down into methods of extracting better models from our users and domain experts, and apply software patterns that let us add and evolve to the model, without it becoming a rigid monolith.

Focused Business Model

From within the text of the work by Eric Evans, you will soon find that there is a heavy emphasis upon the business side of the equation – there is constant reference to Domain Experts. These Domain Experts represent the business, and should be intimately familiar with it’s inner workings. Not the workings of the software, or the way the business analysts see the software – but the business itself.

Therefore, you will find it hard if not impossible, to gain full benefit out of DDD if you do not have Domain Experts up close and personal for the duration of the project – this means that doing DDD on an ISV style application will be hard, you just don’t have the access to the business model of your customers in the way that you should.

It will also be hard to fit DDD to your project if your requirements are too flexible or generic, as again a lot of ISV products are by their nature. DDD is very geared towards providing a highly bespoke solution for an individual business.

What DDD is good at is drilling deep into a business model, and turning that business into a software model.

Internal Applications

Obviously from what I have said so far, DDD is best suited to large projects, where the development team is in-house with the business they are providing a solution for. This ensures that you can gain maximum benefit from what DDD has to offer.

Outsourced Applications

If your development team is outsourced, but writing a bespoke application for a single client, then DDD could be made to work. The key to doing this successfully would be ensuring you had constant access to domain experts, and that their time was not in high demand elsewhere. Constant verification with the Domain Experts would be an important aspect of making this work, and obviously this would be easier with the team on the client’s site.

ISV Applications

By their nature, ISV applications have two qualities that are not a good fit for DDD … they have very generic requirements, and they have highly user customisable models. These kind of applications may well benefit from a lot of the common sense in DDD, and some of the patterns, but DDD will be no magic bullet here.

Data Centric Applications

Some applications are fundamentally just data manipulation programs. Obviously all applications deal with moving data around, but some live for the data and some live for the logic. DDD is very firmly in the logic camp – so is not suited to applications where the primary focus is on retrieving data. modifying that data, and then putting it back into a database.

For data centric operations you would probably be better off using something like an Active Record pattern, or even a DAL over stored procedures. You may find some benefits in some of the more cursory aspects of DDD, and perhaps using some of the terminology, but trying to make DDD fit here will not be a pleasant experience.

The Bad News

Probably 95% of all software applications fall into the “not so good for using DDD” categories.

Most are fundamentally Data Centric – most websites are, most desktop applications are … fundamentally most data updating and reporting applications are data centric.

Of the remaining applications, a large percentage don’t come close to being complex. They may be tricky, or big, but not complex.

The Good News

For the 5% of applications where DDD is a good fit, it is a very good fit. For those situations, DDD will help you crack a very tough nut. Here, DDD may be the silver bullet for that werewolf that your manager just pointed to your desk.

And even if your application isn’t in that 5%, there is a wealth of wisdom and experience encapsulated in Domain Driven Design – use what you think applies to your situation, and you will find your software becoming more flexible, more reactive to your audience, and easier to understand – just don’t expect miracles, and beware of over complicating your code for the sake of it – sometimes simpler really is better.

In Conclusion

There are no hard and fast rules about what DDD is best suited to, and I just made those statistics up, but no software methodology is going to be the miracle cure.

Take from DDD what you think benefits you and your situation – but accept that it cannot be everything to every person.

Previously:

1) Domain Driven Design: A Step by Step Guide
2) DDD: The Ubiquitous Language
3) DDD: Bounded Contexts
4) DDD: There Is No Database
5) DDD: Command Query Separation as an Architectural Concept
6) DDD: Entities and Value Objects
7) DDD: Where is the Code?
8) DDD: Download an eBook of the Series
9) DDD: Aggregates and Aggregate Roots
10) DDD: Services

Reference:

InfoQ Free eBook : Domain Driven Design Quickly
Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)

del.icio.us Tags: DDD,Domain Driven Design,Practices and Principles


Posted 02-18-2009 7:20 PM by Jak Charlton

[Advertisement]

Comments

DotNetShoutout wrote DDD: What Kind of Applications Is It Suited To? - Casey Charlton - Insane World
on 02-18-2009 7:48 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Eduardo Scoz wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-18-2009 8:02 PM

I strongly disagree with most of your observations.

DDD is not supposed "to be used" when you have a well defined business model. DDD is the tool that will HELP YOU TO DEFINE a business model.

All applications have a business model; that's why the application is created in the first place. Most of them, though (your 95%?), have the business logic totally mixed up with presentation logic and persistence logic, and that makes things untestable.

Using DDD allows you to focus in the Domain first, and then later in the presentation; hence the name Domain-DRIVEN-design.

Casey wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-19-2009 2:13 AM

A business has a business model, it has nothing to do with software or developers. If your business does not have a well defined business model, you will fail

It is not the job of DDD to write the company business plan

Reflective Perspective - Chris Alcock » The Morning Brew #290 wrote Reflective Perspective - Chris Alcock » The Morning Brew #290
on 02-19-2009 2:26 AM

Pingback from  Reflective Perspective - Chris Alcock  » The Morning Brew #290

zihotki wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-19-2009 7:15 AM

Hey, I know this cube! This is a borg cube from Star Track :)

Thanks for a good and interesting book!

Joe wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-19-2009 12:10 PM

Thanks Casey -- that answered a lot of questions that I had.  

Now if you could explain how something that is applicable for a small amount of applications is one of the top 5 buzzwords in current use....

Casey wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-19-2009 1:14 PM

@joe

The terminology is easy to pick up, so people presume that if the have a Domain then they are doing DDD

It's a good buzzword, so people put it on their CV just like TDD and Agile before it... Managers recruit people with it on their CV as they have heard it is the miracle cure

And a million other reasons ...

Casey Charlton - Insane World wrote DDD: The Repository Pattern
on 02-20-2009 3:30 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Community Blogs wrote DDD: The Repository Pattern
on 02-20-2009 4:12 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Oziel Jose wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-20-2009 8:54 AM

I'm sorry, i disagree with you, almost everything is data centric, but how things are supposed to be manipulated? thats up with the business model to know and where is it? and what it does? this has to be translated to code, and has to be done in such a way that the developer understands the business model as well as the next programmer.

Even if the whole idea of DDD shouldn't be followed step by step, the concepts can reveal obscure things that sometimes not even the stakeholders realized it existed, so either way the development is richer with the proper information.

I believe that nothing on IT is take it or leave it, everything has a place for applicability, even partially, and DDD already made me focus more on the problem regardless of the complete concept.

Jak Charlton wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-20-2009 9:05 AM

@Oziel

Behaviour centric systems are not data centric ... perhaps you have only encountered data centric system, or come from a background where this is prevalent - DDD is about behaviour not about data, the data is secondary.

So for example, the last system I worked on in DDD was a supply chain management system. There was very little data in the system - almost all of the hard work was around moving messages, changing states, workflows, and similar tasks.

The project I worked on after that was a CMS system, where there was a massive amount of data, and very little behaviour. This was not suitable for DDD, other than to borrow a few patterns and terms

The "business model" has absolutely nothing to do with code or developers - a business has a business model. They would have a business model if no software existed. It is the job of DDD to turn a business model into a software model.

Like I said, 95% (made up) of systems are data centric - so I would expect most developers spend their life inside data centric systems, not behavioural ones.

Eduardo Scoz wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-20-2009 6:40 PM

I don't know anything about the CMS you were working on, but most CMS's have a lot of business rules that have to be modeled into the software. The fact that you have "a massive amount of data" does not mean that the rules are not there.

Honestly, the only thing I can think of when I read your last comment is that your application ended up being a lot of forms, bounded directly to the database, and with all the logic thrown together with duct tape in the rendering of the page (be it with asp, php, or anything else).

It's ok if your application (and 95% of the apps around, probably) are written this way, but I think its an absurd for you to say that because of that 95% of the applications don't have a domain.

I would suggest you to spend 15 mins and watch one of the introductory Rails videos where they demo how you create a very simple blog engine (the lamest CMS around?), and you'll see how you have a domain in there.

95% of the systems ARE NOT data centric. Developers like you just want that to be true.

Casey wrote re: DDD: What Kind of Applications Is It Suited To?
on 02-21-2009 2:48 AM

Having a domain does not mean you ate doing DDD or need to be. Having a lot of rules does not mean you have a behaviour centric system

From your comments, again I presume you work in the data space more often than not, most developers including myself do.

Rails is by design a data centric framework - AR is a primary feature, and AR is a data centric pattern

Try using rails/AR to write a supply chain management system, or the shipping example from the book, and you will find a lot of friction

Having written more than my fair share of CMS systems, and written around even more, I am fairly confident they are simple systems to write, hugely generic, have very little complexity, an forms over data does 90% of the job easily. They are on the whole, retrieve/display ... They barely even have any update. If CRUD apps are not suited to DDD, then R apps most certainly aren't .. almost all your code would be in the reporting context  

Casey Charlton - Insane World wrote DDD: Living In The Enterprise
on 02-21-2009 4:25 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Community Blogs wrote DDD: Living In The Enterprise
on 02-21-2009 4:48 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: The Repository Pattern
on 02-21-2009 10:42 AM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

Insane World wrote DDD: Living In The Enterprise
on 02-21-2009 10:42 AM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

DDD Step By Step wrote DDD: The Repository Pattern
on 02-22-2009 3:36 PM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

DDD Step By Step wrote DDD: Living In The Enterprise
on 02-22-2009 3:37 PM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: Living In The Enterprise
on 02-26-2009 4:08 PM

No, not that Enterprise! The other Enterprise – the big amorphous one that organisation spent a fortune

Insane World wrote DDD: The Repository Pattern
on 02-26-2009 4:08 PM

I seem to have taken a fairly long time to get here, and it has been mentioned in passing, but now we

IHateSpaghetti {code} wrote Blog Carnival #14
on 03-01-2009 1:08 PM

Software architecture Evolutionary Design and Acyclic componentization by Patrick Smacchia Carnival of

DDD: Bounded Contexts at Mark Needham wrote DDD: Bounded Contexts at Mark Needham
on 03-08-2009 3:31 AM

Pingback from  DDD: Bounded Contexts at Mark Needham

alf wrote re: DDD: What Kind of Applications Is It Suited To?
on 03-16-2009 1:52 PM

I kind of agree with both Casey and Eduardo.

I dont think you can say that DDD will fit or not as a methodology for building a CMS. It all depends on what kind of CMS you are building. If you are a software company planning to make off-the-shelf CMS systems you could benefit from applying DDD in the long run. Betweeen your developers and other co-workers a ubiquitous language could evolve and support in the development process. Since CMS is your domain the logical structuring you get by applying DDD would probably be a good solution.

On the other hand, in most cases you're not building a off-the-shelf CMS but a CMS specific for your purpose (although generic from a functional point of view). In this case you will not get the benefits of applying DDD mainly because the CMS probably is not a big part of your business-processes (Supply-chain-management systems are most of the time). With the small impact the CMS software has on your business the resources avaiable for the development does not match the ones you would have if you were making of-the-shelf software. DDD takes time to perfect. Part 3 of Eric Evans book describes steps to reach a better state, but it's obvious that for a easy CMS system you will neither have the avaible time or other resources for your disposal.

In many cases you actually would buy the off-the-shelf CMS from the first company, and since they're applying DDD it's a good piece of software. It's all connected :-)

My key point is that it really depends on the size of the project and the resources available. In 95% of the cases maybe the biggest problem is your boss telling you to work faster and to have a hack ready at the end of the week.  

-alf

Excuse my bad english people.

Johan N2 wrote re: DDD: What Kind of Applications Is It Suited To?
on 11-04-2009 4:29 AM

LOL!!!!

Get a grip dude...

DDD = OOP and what you say is that 95% of the softwares are not OO suited? You are funny...

The main thing with DDD is that it's a thinking and a model (OOP with convention)... I have made all my past 10 applications with DDD and TDD in my mind and ended up that 5% are not DDD suited...

And I have build CMS apps, webapps, win apps. Silverlight apps. SOA apps... etc...

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)