Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
