Menu
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?
726
Domain-driven design (DDD) is a useful approach that provides excellent guidelines for modeling and building systems, but it is a means to an end, not an end in itself. While the concepts are valid, you lose a lot if you limit yourself to using them only: There actually is a life beyond DDD.
It's neither obsolete, nor antiquated. People in this thread seem to conflate DDD and OOP which is understandable given that 90% of DDD resources target the typical enterprise Java/C# setting.
An aggregate is a domain-driven design pattern. It's a cluster of domain objects (e.g. entity, value object), treated as one single unit. A car is a good example. It consists of wheels, lights and an engine.
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.
161
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
