62

Googling "What kind of applications is DDD suitable for?" gave me the following answer:

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

So what is all the fuss about?!?

The application I am working on is mainly data-centric but still contains some business logic and rules to be applied. Would it be waste of time to start applying DDD techniques? Am I better off using a more conventional Data Access Layer, a model of POCOs and a Business Logic Layer? Or to state it differently - what is a sound alternative to DDD?

JacobE
  • 8,021
  • 7
  • 40
  • 48

7 Answers7

134

Many developers who think DDD is useful for their project fall into the trap that they think what their job is all about is writing code. This isn't the case. A developer's job is about realizing functionality so a problem can be solved through software. This results in the conclusion that writing code isn't the beginning of what a developer is doing, but the end: the code is the result of the whole process BEFORE the code is actually written.

DDD isn't about writing code, it's not a turn-key 10-step process to get great software, it's about that whole process BEFORE the code is written, it's about getting insight in what the problem is all about, what/who participates in which information streams and what do these elements look like, how do they relate to eachother etc. etc. In fact, the most important part of DDD is creating a language which makes conversations between domain experts and developers possible without misinterpretations. This is the 'Ubiquitous Language' Evans talks about. It in effect makes the whole process BEFORE the code is written a process which leaves little to be guessed, things are clear and straight forward. (that's the goal).

The problem with 'how does DDD work in practise' and 'could anyone give me an example of how I write code with DDD?' and the like is really coming from the fact that the people asking these kind of questions focus on writing code, but have no idea WHY they're writing THAT code and not other code. I.o.w.: if you realize that DDD is about discovering WHAT you've to write as functionality and WHY, things fall into place. HOW you're writing that code, that's up to you. But as said: that's not the biggest problem anymore, as you by then already know what you've to write and why.

ViRuSTriNiTy
  • 5,017
  • 2
  • 32
  • 58
Frans Bouma
  • 8,259
  • 1
  • 27
  • 28
  • 25
    It's a way of THINKING, not a way of writing code. The thinking about domains drives your design, which results in code which could be anything. Some people make the mistake to think in code and forget about the thinking, the domain oriented design. – Frans Bouma May 08 '09 at 19:18
  • 10
    +1 excellent description of DDD's benefits. I think it can be summed up as "creating a language which makes conversations between domain experts and developers possible without misinterpretations." – Robert Harvey Oct 10 '09 at 17:56
  • 5
    Well, Wikipedia is defining DDD in a fairly code-centric way, or at least emphasizing the use of certain DDD-specific code design patterns... – alchemical Dec 02 '09 at 23:35
  • 11
    @LuftMensch: yeh well your mistake there is thinking that Wikipedia is a definitive resource – Matt Kocaj Dec 07 '09 at 06:51
  • 8
    It's one of the largest collaborative compendiums around, anyone can edit it...if it's there it at least means that's how most / lots of people are understanding something...in reality most people don't see DDD as simple understanding the business--that's something we've always needed to do. In practice, it would seem to be that + exchanging DataTables for custom storage objects for everything...and repositories & factories to manage and create those objects...then you have often many, many of these objects flying around-hence best to apply these patterns only where they're really useful. – alchemical Dec 16 '09 at 00:38
  • Is it possible creating the ubiquitous language by using open linked data vocabs? – inf3rno Sep 21 '14 at 22:55
  • Frans would be correct in terms of some of the practices of DDD, such as establishing a ubiquitous language, but wrong in terms of other DDD concepts, such as persistence ignorance, as pointed out by @IharizakaRahaingoson below. – CShark Jul 21 '18 at 10:39
16

Sorry but if DDD were only a way of thinking as Frans Bouma says, then it would not recommend such things as Persistence Ignorance. This is dismissing others as somewhat underclass developers.

PI, for which DDD has at least a bias, is an architectural choice. It is not a way of thinking anymore ; it is already something being served to you, with most of the time too vague warnings to be of any use: "not suited for everything".

But deciding to go the PI way or not is a challenge in itself, and you can't call names someone ("a coder") if he feels uneasy about this.

Take an ERP package with all-over the place a MS Access-like interface: grids with running totals, auto-updating columns and pageless scrolling on a 100 000 records. Clearly a DDD approach is suited for thinking of how to go about this app. But in years I have never seen anyone - neither in books nor online, going though evidence backed explanations, let alone real life code examples, of how PI could deal with this ubiquitous situation for anyone wanting to deliver commercial grade apps and user experiences.

Don't want to get religious on this. DDD and DAL proponents tend to be overly religious and may drive away those who have been bitten once but who are/were open-minded. Many just want to confront real-life experiences (i.e. THINK), and not get served with just Cats, Cars, and basic Order/OrdersItems (i.e. poor CODE) to support the preaching.

Iharizaka Rahaingoson
  • 177
  • 1
  • 2
  • 3
    I know.. I'm so over the stupid Cars and OrderLine examples. The _moment_ I stepped into a real ERP project I was hit with some very difficult situations that are quite common situations but nothing in all the DDD reading i've done ever touched on. – frezq Sep 27 '18 at 16:38
9

Here is a very similar question: Do you allow the Web Tier to access the DAL directly?

I use DDD for all my projects. On the smaller applications some of the concepts don't apply, but I find many of the aspects are applicable on all projects regardless of size.

Community
  • 1
  • 1
Chuck Conway
  • 16,287
  • 11
  • 58
  • 101
  • agreed- smaller projects may not need every thing - in fact some smaller project may need different things left out than others. – Preet Sangha May 01 '09 at 08:34
  • well, the size of mu project is quite big... do you think DD would do more harm than help when it is data centric? – JacobE May 01 '09 at 08:36
8

you know, sometimes the 5% makes more money than all the other 95% - that's why DDD exists.

it's for specific complex large system.

Francis
  • 11,388
  • 2
  • 33
  • 37
  • Not always... A "money" domain is a relatively small system that benefits from DDD, and is often used to demonstrate the concept of DDD in the small. – JasonTrue Sep 03 '09 at 19:50
  • @JasonTrue: An enterprise system doesn't have to have anything to do with money in the conceptual sense. – UpTheCreek Apr 22 '11 at 11:23
  • I was just being cute by repeating "money", because my point was that there are small systems that benefit from DDD, not only large, complex ones. – JasonTrue Apr 22 '11 at 16:35
7

DDD is about software that will be maintained for a while. To me this means that it needs to express ideas that will change with the domain. Sure a simple app may be perfect for a short delivery time and short implementation time. However if you need to grow the software then DDD principles will help immensely. DDD may be hard up front but once you get the idea of the ubiquitous language and the separation concerns then things do start to become easy.

Preet Sangha
  • 64,563
  • 18
  • 145
  • 216
5

  • As your app is mainly data-centric, perhaps your architecture could be mainly conventional.

  • For the aspects where you have more logic and potential domain or value objects, perhaps you could leverage some of the DDD ideas to organize the code.

  • In general, the "sound alternative" is to keep things as simple as possible, use the DDD concepts where useful, and don't unnecessarily complicate things, as the article advises.

I'm starting a similar project now, it is a mix of data manipulation and more logic/algorithm driven areas. I'd similarly like to take the parts of DDD that will benefit the project, but not try to force it on areas where it may be counter-productive.

alchemical
  • 13,559
  • 23
  • 83
  • 110
  • 6
    DDD is a gimmick, it does not bring ANY new ideas to the table, it's just pure old OOP/OOD with a bias for latest developments in coding practices. "First talk to the domain experts, identify key abstractions" is the first thing you'd read in any 30-year-old book on OOP. "Encapsulate functionality inside domain classes except for when it doesn't make sense"... Duh! – rustyx Aug 15 '14 at 08:32
5

If you read the article a little more, you see this:

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.

That's why the fuss about it.

Mnementh
  • 50,487
  • 48
  • 148
  • 202
  • 2
    you'll also see this: "just don’t expect miracles, and beware of over complicating your code for the sake of it – sometimes simpler really is better." – alchemical Dec 02 '09 at 23:40
  • @Luft Mensch => "Simple is better than complex. Complex is better than complicated. | @fedecarg" – Arnis Lapsa Feb 09 '10 at 23:04