I’m trying to apply DDD, CQRS (saga, fire and forget principle, etc), ES in my current project, with help of akka. Never done it before in real projects (just played a litle bit), sounds great in theory, blablabla.

But sometimes it frustrates me, sometimes I think it just buzzwords.

Do you have experience with those techniques in the real project? If so, is it worth it or it just complicates the system?

  • 5
    These principles definitely provides value in many systems, but they are not appropriate for all kinds of projects. Think of it like a hammer. Is a hammer useful for some tasks? Yes! Is a hammer the best tool for any kind of task? No! Is using a hammer a waste of time? Well, if you use it for the wrong task it will be worse than just a waste of time. But if you try knocking in a nail without a hammer you are also at best wasting time.
    – JacquesB
    Jul 21, 2017 at 7:45
  • DDD is really just a small step from a "traditional" anemic model design, where all business logic resides in services. So to start adapting DDD you do not have to change a lot, which is great. But, from my experience, it makes your systems more stable and predictable.
    – Andy
    Jul 21, 2017 at 8:24
  • 2
    Ok, why so many down votes? I'm sure many people who start with these thing asks this question themselves. I hurt somebody's feelings or is it stupid question?)
    – Teimuraz
    Dec 7, 2017 at 22:11
  • Not a stupid question. Probably they wanted to see that you had done some research, as this isn't a forum, it's better to be more specific. I.e. "I think these are the benefits x, y, and z. But I'm not convinced and see these downside: a, b, and c"
    – Jono
    May 24, 2018 at 3:32

3 Answers 3


Well they are three separate things and they are real things not just buzz words. But....

  • Domain Driven Design. I've seen this used quiet commonly now, at least in a 'lite' fashion. I think it does help to define and break down a system into component parts.

  • Command Query Segregation. Although there are cases where you want to have a read only db and a write db. Universally applying the pattern with command objects and the like doesn't seem to pay off where I've seen it attempted.

  • Event Sourcing. I've seen this applied to parts of a system, but its never struck me as offering much more benefit than an audit trail of events. It adds a medium amount of complexity and forces you to think about some important error conditions, colliding events etc so there is a big side effect upside to it.

As always with these things there is more than one view of what they mean and more than one way of implementing each view.

When a single implementation gets popular and is thrashed out over time it can be said to be mature.

Unit this happens, the potential to misapply or misunderstand the implementation you choose is quiet high. Which means people can end up with somewhat hacky solutions.

You should take extra time to understand and test any pattern that is new to you and steer clear of using immature tech in the core of your app.


Sometimes the most important principles in software engineering are K.I.S.S and Y.A.G.N.I.

All software engineering principles, guidelines, methodologies are merely suggestions which exist to steer you down a route where you may end up with a better solution than the one which you might otherwise have written if you'd simply hammered out a solution based on the first thought that popped into your head.

DDD, CQRS, ES and others are popular for a reason - because somebody else tried the "Nike" approach of Just Do It, found themselves with a codebase resembling a Big Ball of Mud with a vast back catalogue of Technical Debt, identified the mistakes they made in their design or process, and bundled up the advice in order to help others avoid that same fate (and/or how to dig themselves out of that hole once they're already in too deep).

DDD, CQRS, ES, et-al are not Buzzwords (real developers apply them to real projects with positive results), but they are not Silver Bullets either. To understand the benefit of any methodology, guideline or principle is to understand not only how to put it into practice, but also when to follow it, and when you won't benefit from it. Some problems particularly lend themselves to particular techniques, whereas others need a different approach

To provide a concrete answer to the question "Are they worth it?" (Which I interpret to mean "should I use them right now?") would be to take a deep look at the specific project you're working on and take a judgement call for that project, based on the types of features you need to deliver (now vs in future), estimated time, complexity, budget, deadlines, etc.

The typical 'cost' of DDD/CQRS/ES is more time spent iterating on your original design and throwing away or refactoring the bits which aren't working - no doubt that even if you follow these approaches your initial implementation will include many aspects of the 'Nike'/Just-do-it solution; the key difference is how you progress after throwing together the prototype or initial solution.

As a developer, its more important to ensure your own understanding on how to apply DDD and CQRS, and how to recognise whether you're approaching your project the right way. It's likely you'll find them useful at some point, although the way to make the leap is to use them in anger (i.e. attempt to apply them to a real project and iterate your design until you feel comfortable with it).

Time spent trying new things is rarely wasted even if the process is frustrating and results in failure (Some might even say that you will learn a lot more from failure). It's absolutely worth spending your own time being persistent in learning different ways to approach different problems - frustration is a normal part of this process; it's a sign that there are things you still don't understand, but that doesn't mean they aren't worth understanding. Gaining greater knowledge and understanding is likely to lead toward becoming a "better" developer, even if you don't actually put any of that knowledge into practice on your current project or with your current employer.


Don't do it... its a flawed design policy. Even Greg Young questions its use - but yet peddles his conferences spreading confusion and chaos in systems. There are some specific use cases where auditing may be required - but there a simple command pattern will suffice. Alot of system designers have herd mentality on the next big thing, mainly to show off to peers, i think. Or add to their resume. The most important thing is to build a reliable, easy to maintain, easy to understand system that grows with the product & your company.

Microsoft, Google, Facebook, Twitter, major financial institutions - all billion dollar companies that did not need to resort to all these trendy flashy ridiculous ideas. So keep it sane, and use your common sense when designing your system. Don't get sucked in.


Not the answer you're looking for? Browse other questions tagged or ask your own question.