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
The 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