We Are Not Doing DDD

Recently I joined a new project, and within reason, and excluding some legacy systems we have to talk to, we have the “luxury” of an almost greenfield project. Probably as greenfield as you realistically get anyway.

I was brought in partially as a good old fashioned coder (the project needed another person cutting code) and partly as guys in the team knew my blog and general approach to software development and wanted to inject some of those ideas into the team. I’m not sure exactly what they were expecting, and I’m not sure if they got what they were expecting, but suffice to say the first two weeks has been turbulent and frenzied.

I’m certainly not known for my subtlety, nor for my coding skills which are by no means the best you can buy in. What I feel is my key strength is my ability to look at the wider picture than sometimes teams have the luxury to do, and to push some of my enthusiasm and energy into a project. I’m sure I’ll blog in the near future about the actual impact my presence has had on the team and the project, but this blog is primarily about why we are not going to be doing DDD.

But Casey Does Domain-Driven Design

One of the factors that made the client hire me was my knowledge around DDD, or at least my projection of that knowledge on the web. It was certainly something they felt could have helped some of their past and ongoing projects, and something they thought would be a real help to them. I don’t think anyone suspected I would come in and say “Hey guys, lets all do full on DDD”, so luckily for them I didn’t, what may have surprised them is that I did pretty much the opposite. In fact my early assessment was this project really didn’t have any need for most of the stuff in DDD – fundamentally it, like the other projects in progress by the same team, was a CRUD application at heart. Data out of the DB, a bit of manipulation, some input by users and services, and dump the data back to the DB.

Many out there disagree with my general statement that CRUD applications don’t make good candidates for DDD – but not only do I stand by that statement, but two of the other client’s projects nearing completion showed some of the real pitfalls of DDD. While previous projects had attempted to use parts of DDD to help simplify their applications, it had not all gone according to plan.

What Goes Wrong With DDD Over CRUD – The DB Domain Model

The first most obvious weakness of the systems that existed was the Domain Model. It had started with all the best intentions – there was a legacy database that acted as the primary store for the business, and many different systems used and updated this database. So NHibernate was chosen as a way to create a Domain Model over the database, to abstract the system away from the DB and to treat it as a legacy system.

Unfortunately one of the primary requisites of DDD is direct involvement and commitment from the business to the project  and in this case that wasn’t part of the project. The team had to come up with their own Domain Model – and in doing so had fallen into the classic pitfall of creating a “domain model” that mirrored the legacy database. Now not only was there a legacy database, but essentially there was a legacy domain model too. A large amount of work was put into getting this NHibernate model right, and in hindsight it has probably consumed disproportionate resources to get this model overlaying the DB.

In addition, although at present it simplifies many operations against the DB, it does not abstract the code base from the database, it just acts as a heavyweight data access layer. Worse still, many of the “hacks” that had to be made to get NHibernate to work with the (frankly terrible) underlying database structure, had actually made the system very fragile, and fairly rigid.

Lesson to be learned: Do not drive your domain model from the database, drive it from the Domain Experts, user stories and use cases. Without significant commitment from your business to provide you with those experts, you are at risk of creating a significant amount of code, with no quantifiable benefit.

What Goes Wrong With DDD – Where is The Ubiquitous Language?

A somewhat related problem that is now obvious, again in hindsight, is that there was no clear attempt made to extract any kind of Ubiquitous Language out of the (non-existent) domain experts, nor from the business analysts. The language between the teams has fallen into the classic pitfall of a language confused across development teams, technical support teams, legacy systems, and business terminology that was not clearly defined nor understood.

Lesson to be learned: Get your language sorted out early on. Insist upon a basic glossary of terms at the very minimum, regardless of whether you do DDD or not. This will save countless hours of mistakes and confusion, and will get new developers and business people up to speed on the project in record time.

What Goes Wrong With DDD – Services Services Services!

I sat down early on with numerous team members and the architect who was in the unenviable position of making all this stuff work, and ensuring all the new stuff learned from previous mistakes and moved forward.

One of the things that became apparent to me was that while discussing architectures, the term “Services” was in frequent use, more than frequent to be honest, it permeated through everything. It was a term that business analysts and project managers were comfortable with, and perhaps that was the reason that “Services” was the terminology for decoupling things. From that it soon became obvious that Services of all kinds had become intrinsic to the current codebase, from Web Services, to Application Services, to Domain Services, and on and on.

Now, there is nothing wrong with “Services” per se, but interestingly when I suggested a new architecture for the new project, and discussed this with various people, I managed to explain the entire new architecture with almost no use of the word “Services”.

When I pointed this out, it soon became clear we could discuss a decoupled system, with little direct reference to “Services”, as fundamentally Services are an implementation detail, and have little important to the overall architecture of a system. Now instead of talking about Service being called, we can discuss messages being moved around the system, without any need to worry about what consumes them, or how they are delivered. The final architecture includes services for sure, but they are the implementation of a much more abstract concept.

Lesson learned: Technical language can become the norm, and then it tends to be the solution to every problem. Step back from things once in a while, and see if the terminology you are using is driving your architecture and design. Try to avoid using implementation terminology in relation to things like architecture, or it will drive the design.

So Where Are We Now?

The one really big thing that has happened over the past two weeks is that the introduction of some new blood to the team, along with some new ideas, has really revitalised the team. Everyone has new found energy. We also have a broad consensus of what didn’t go right on the last two projects, and the things that went well – we now have a strong idea of how to build on the strengths of the existing systems, and where we need to compensate for the things that didn’t turn out as planned.

Luckily the teams involved are all really eager to learn, and really keen to make each and every system better – and that alone will make a huge impact to how successful this project will be.

Well, this post has turned into a bit of an EPIC … and is far too long to continue without boring everyone to death … so I will post the concluding part soon. And with luck I may explain my opening statement … “We Are NOT Doing DDD”.


Posted 04-08-2009 9:34 PM by Jak Charlton

[Advertisement]

Comments

DotNetShoutout wrote We Are Not Doing DDD - Casey Charlton - Devlicio.us
on 04-08-2009 7:22 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

HireDotnetexpert.com wrote re: We Are Not Doing DDD
on 04-09-2009 12:42 AM

you have summed up 90% of the projects out there! Very good story, awaiting for part II.

Ollie Riches wrote re: We Are Not Doing DDD
on 04-09-2009 7:33 AM

I'd be interested in hearing the architectural style that's been adopted - Active Record, DataSets\DataTables etc..

And whether DDD-Lite is coming into play...

Haider Abdullah wrote re: We Are Not Doing DDD
on 04-09-2009 10:46 AM

Casey,

Just to clear up my own ignorance on the matter - does the term 'Service' necessarily have to be considered an implementation detail?

For instance, could a term like 'Credit Card Authorization Service' not be a part of the UL? The implementation detail would be how that particular service is implemented/accessed - Remoting/WCF/Plain old ASP.NET asmx, etc.  

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 10:54 AM

Please Please Please there are no CRUD applications. stop using that excuse. You mean you don't have if statements anywhere? look in the database you'll probably find plenty in stored procs (where clause are also conditional logic).

The only CRUD application out there is the one that does not have conditional logic and such application does not exists. if you have logic then it's domain logic and you need DDD.

Tim Barcz wrote re: We Are Not Doing DDD
on 04-09-2009 12:17 PM

Casey,

I thank you for the honesty in the post above and the background on the project.  I'm sure you are familiar with this, but DDD has tended to be a buzz word.  I appreciate that while you are a "DDD guy" you don't beat DDD into every project you work on, it means you probably understand DDD better than the average guy.

Tim

Tim Barcz wrote re: We Are Not Doing DDD
on 04-09-2009 12:22 PM

@DaRage "The only CRUD application out there is the one that does not have conditional logic and such application does not exists. if you have logic then it's domain logic and you need DDD."

Seriously?

It's not CRUD or DDD.  It choosing the right tool for the application.  Fowler suggests Domain Models aren't good for many applications and suggests the Transaction Script pattern.

Your statement of, "if you have logic then it's domain logic and you need DDD" seems a bit misguided...how about:

"You have more than two people in your family and therefore must buy a bus for transportation"

"The small drink is not enough and therefore you must buy the MEGA GULP" (what about medium, or large)?

It is not black versus white, there are several shades of architectural gray in there.

Michael D. Hall wrote re: We Are Not Doing DDD
on 04-09-2009 1:31 PM

@DaRage, So, huh, everything that has logic must use DDD?

Do they have IF statements in C?

Do they have IF statements in T-SQL?

Do they have IF statements in HLA?

Are there well-crafted applications written in those languages? Yes.

Is DDD the only way to craft well-designed applications? No.

DDD is *a* way to write applications. Don't mistake "a" with "the".

Do you write device drivers using DDD? How about embedded systems? No? Well that must mean they're crap! Right? Is Linux written using DDD? Uh, nope.

Do what works for your project, your team, your company and, ultimately, yourself.

And yes, there are simple CRUD applications. nyeh.

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 3:08 PM

@Tim Barcz

Seriously.

Your analogies don't hold because the domain model is very flexible and can be big and small. thus building an small application can be done using DDD with a domain as small as has to be. This way it will be open for growth.

I think what' s being mention time and time again as DDD vs CRUD is in fact "proper way" vs. "dirty job". I agree with you that dirty job is sometimes the way to go. Certainly not for important projects though.

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 3:34 PM

@Michael D. Hall

bringing device drivers and operating system development into the discussion is irrelevant. Yes application is a very wide term and you can literally interpret my post and apply it to assembly language as well. I don't think I can give you a definitive definition what application can DDD applicable for but I think you can find it in the reason why Object Orientation was invented to provide an alternative represent logic in a way that languages like  C, TSQL, HLA are incapable of.

Practically, almost all the applications discussed here are good candidates and non of them are part of your irrelevant examples.

Jak Charlton wrote re: We Are Not Doing DDD
on 04-09-2009 3:51 PM

@DaRage

I think you probably lack a perspective here, there are most certainly CRUD applications- having worked on maybe 20+ projects over the last 5 years, I can categorically state that (IMO) all but a few of them were firmly in the CRUD camp.

DDD is a high commitment and high cost solution to  a very rare problem - complexity. As a former colleague said to me tonight ... "software problems are almost never complex - you just don't understand the problem".

Shifting a million records, with thousands of associated if statements, and complex validations is still a CRUD system, it's just a big CRUD system ...

Don't confuse if/switch/decisions/rules/workflow/pipelines/decisions/scale/services/etc with complexity ... they are not related.

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 4:01 PM

@Casey Charlton

I disagree that simplicity and DDD are mutually exclusive. Can you please provide an example of classic CRUD application so that we establish a reference?

Daniel Fernandes wrote re: We Are Not Doing DDD
on 04-09-2009 4:23 PM

IMHO DDD does require a lot of upfront work in getting that Ubiquitous Language right. Without it there isn't DDD from talking to Casey.

My assumption is that I don't think the UL cannot be fully approached iteratively and threrefore requires a fair amount of upfront work by both the developers and the Business Experts.

That in itself is sadly something I haven't been given the chance to do in most projects I have been involved with in the past few years.

The confusion about DDD is that there is Domain on there and somehow provides a false definition of the practice. It's not as if only DDD is based around a Domain which is a well understood pattern.

DDD focuses on the fluency of the Domain in that it provives a strong symbiosis with what the business is doing.

I've been invovled in projects where the Domain was purely a technical abstraction of the problem domain and they were equally as successful as any project can get.

At the end of the day, as long as one can continuously integrate their changes into a codebase with confidence and the project is doing what it's supposed to do then you're on the right path.

Daniel

Jak Charlton wrote re: We Are Not Doing DDD
on 04-09-2009 4:23 PM

OK ... how about a blog system ... you are using one right now...

How about a shopping cart/ecommerce system ...

How about an online price comparison site...

How about a hedge fund data reporting system ...

And the list goes on ... none of them have any complexity in any form...  and none of them need much more than a lot of data processing and crunching. They all have small aspects that do a "bit" more ... but unless you are Amazon, they don't need DDD ... and if you are Amazon, you aren't going to use DDD to solve their complexity

Now give an example of an application domain you think is appropriate for DDD ...

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 5:14 PM

@Casey Charlton

I wholeheartedly disagree with you. I worked an a multiple e-commerce systems and what i'm going to say now comes from direct experience for many years. E-commerce systems are very complex systems with Product catalog, Order Tracking, Inventory Management, Pricing, Taxing, Discounts, Customer notifications and much more that's without going into eye candy features like wish lists.

where would you do what you call "data processing and crunching". stored procs? stateles services? code behind?

I repeat, from experience I've seen medium e-commerce systems turn in a ball of mud by not using DDD that cost millions of dollars of maintenance and lost customers.

That's why you have e-commerce products that costs 10s of thousands for dollars like Mircrosoft Commerce Server. And even those generic solutions often don't meet real life customer demands.

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 5:23 PM

@Casey Charlton

I forgot to say, blog systems can be complex because I developed one and now it's in it's second year and the  features keep adding. but even for the simplest blog system, I don't see a harm in developing it using DDD. There is no problem to me of having a domain with classes that are only hold state. The important thing is that it's developed starting (driven) by the domain. If it's a simple problem, time wise it will not have much difference than developing it the "dirty way" but in the future it will be open expansion.

DDD is not mutually exclusive neither with simplicity nor productivity.

Jak Charlton wrote re: We Are Not Doing DDD
on 04-09-2009 5:34 PM

Then we have a strong disagreement. Having worked on ecommerce systems pushing upwards of £40 million business per year, I am fairly happy that there was no significant behaviour involved at any stage - almost pure data processing - and one of those I am particularly thinking of also handled insurance quotations, a mapping system, a route mapping system, and a hotel booking system.

So what systems have you successfully applied DDD to? Have you blogged about these experiences? As you are anonymous it's hard to tell ...

Jak Charlton wrote re: We Are Not Doing DDD
on 04-09-2009 5:42 PM

@Haider

Service can indeed enter the UL as in your example ... when a word that is linked to implementation starts being pervasive though - it's an architecture smell ...  

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 7:26 PM

@Casey Charlton

I don't see how my anonymous status being related to the discussion nor does being a blogger really hold any weight to the questions at hand.

I sense you're being defensive about the whole issue and I will stop participating.

I just have one comment that popped in my head after I posted my last comment: "Why would an employer pay your salary to solve a simple problem? would you hire yourself to solve what you call a CRUD system?" for me the answer is no.

Jak Charlton wrote re: We Are Not Doing DDD
on 04-09-2009 7:31 PM

@DaRage

LOL ... I asked what your experiences were ... if you don't want to share some real examples and discuss real scenarios, then it is hard to talk from a common vantage point.  Getting defensive is "I will stop participating" .

Would I hire me to write a simple or complex CRUD system ... probably, but only because I will still do it better than 90% of the people out there, and better than 100% of the people that try to apply the wrong methodology to the wrong problem.

The skill in development is not applying one methodology all the time, it is knowing when to use which tool for which job - that is what employers pay me for.

DaRage wrote re: We Are Not Doing DDD
on 04-09-2009 8:28 PM

@Casey Charlton

Sorry, I thought I sensed a defensive tone. I guess I was wrong.

My experience with DDD is recent the concept is recent too. I have so far implement one system with DDD. The first experience is rough because there are a lot questions to answer when you go from theory to implemnetation. The system is user registration, billing management and some reporting. There wasn't a lot of logic involved but starting with the domain made the design clean and easy to understand as well testable. I don't think there was a lot productivity loss because of using DDD. Before that all the system I worked on were database driven. My experience is with a little bit of complexity, no matter how careful you are, you'll end up with mudded domain if you start from the database.

My main disagreement with you is that you say DDD is only worth applying to Amazon scale applications. From my last e-commerce system that I mentioned earlier that took 1.5 years to release and still under active development for 3 years. The system was greenfield project to re-engineer 7 years old cold fusion e-commerce system. We took good care of crafting the database which is around 500 tables. The main lesson I learnt is that the domain model didn't ended up as clean and maintainable to match the effort spent in crafting the solution. If I would start again I would definitely choose DDD. And that's system is no where near Amazon scale.

Hiredotnetexpert.com wrote re: We Are Not Doing DDD
on 04-10-2009 2:06 AM

@DaRage

I think you probably are working in a corporation shielded about real problems when you work on a consulting gig.

When you are employed as a consultant you are not paid for pushing up your methodologies. You are paid for solution to a problem. It must be time bound as well as to the budget. That's what consulting  clients care about.

Jak Charlton wrote re: We Are Not Doing DDD
on 04-10-2009 3:31 AM

@DaRage

OK, your position is becoming clearer now. I don't think you are doing DDD though. Specifically the term and concept of a Domain exists outside of DDD, and existed long before.

You didn't mention your Domain Experts, your Ubiquitous Language, how your Domain evolved from those conversations and concepts. These are the things that are core to DDD. While you are trying to use some of the terms and patterns from DDD, and this in itself has HUGE benefits, do not confuse using good concepts with "doing DDD".

I think you will benefit from waiting on the second part of this post to understand further why I still say We Are Not Doing DDD ... and why not ...

Michael D. Hall wrote re: We Are Not Doing DDD
on 04-10-2009 4:36 AM

@DaRage I was trying to make a point by bringing up other technologies. You seemed to be implying that DDD was the only way to develop software. I was merely disagreeing with you, there are a multitude of practices that can be leverage depending on the intent of the system under development. Also, not everything follows an OO paradigm, and OO itself isn't appropriate for all situations. Just a friendly dissent. :-)

@DaRage wrote re: We Are Not Doing DDD
on 04-10-2009 4:36 AM

@Hiredotnetexpert.com

I agree. When working on consulting job, you're under a lot of pressure to get things done and not done right.

@Casy

It's going to be hard to agree on what's %100 DDD and what's not. In my case i considered the project to be DDD because the domain layer was the driving  in the design and the architecture of the application. The domain itself was driven by requirements and direct communications with the client of the application, which in that case was the marketing department from which the ubiquitous language was derived.

I agree with you that a lot of the DDD concepts where there for a long time but they weren't "driving"  and that's what DDD signifies in my view.

What about you? have you done any real projects with DDD? I've read on your blog about a sample application but I don't remember reading about a real project.

DaRage wrote re: We Are Not Doing DDD
on 04-10-2009 5:31 AM

@Michael

I certainly didn't mean "all" software. I might not have been precise but I wrote my comment within the context of the blog post.

Frankie Jim wrote re: We Are Not Doing DDD
on 04-13-2009 6:50 AM

this is a GREAT discussion guys, I'm newbie to DDD (trying to understand necesity of agregates and work my way through them when accessing other objects) so this comes handy.

What I don't get is CRUD application. What is it? Can someone explain it to me in more detail?

I am usually using repository (sometimes even a service), does it mean I am CRUD?

thanks guys

Jak Charlton wrote re: We Are Not Doing DDD
on 04-13-2009 7:23 AM

@Frankie Jim

For CRUD application, also read "Data Centric Application" ... i.e. if 80% of your application just reads data from a database, modifies it, displays it, updates it, writes it to the database, etc ... then DDD will cost you a lot of development time and effort here, probably for very little return on that time ...

Some will claim all applications are data centric by this definition, and I would say that the vast majority are - which doesn't mean behaviour centric applications don't exist - it just means you haven't yet had the experience of working on one - and therefore haven't yet seen where DDD can really shine

Perhaps read my earlier post around when DDD is appropriate:

dddstepbystep.com/.../blogged-what-kind-of-applications-is-it-suited-to.aspx

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)