Imagine this: you come to an engineer and commission a custom fridge. A couple of weeks pass and you get a message telling you that it’s ready. So you visit the workshop, and indeed, there’s your new and shiny, advanced, extremely polished, and super effective… oven.
Well, that’s a technical marvel for sure, but not exactly what you wanted, right? That’s the exaggerated version of what can happen when your software isn’t made with the DDD principles in mind.
DDD means Domain Driven Design. Domain, as in a domain of knowledge – not to be confused with your web domain. What this really means, however, is that you make stuff for a specific purpose.
If you’re in the business of selling cars, your custom software will be created to acknowledge tire size, engine power, etc. It won’t use the exact same template as, say, some babysitting app that’s also about B2C relations, but of an entirely different variety.
Why should you even bother with DDD?
Simply because the base assumption for DDD is that there’s a model at the core of every software. If this model is properly lined up with your domain, the software will serve you just right. If necessary, you will be able to expand your app with ease, thus making it relevant even as time passes.
This model we mentioned might not be obvious. It may not be outlined openly in the documentation and exist only in the developer’s mind. Still, this core idea behind the software does exist. If it reflects the uniqueness of your domain, the app will serve its purpose.
Like any highly effective investment, DDD requires an entry cost, which includes both money and time. However, it’s a reasonable method of investing in software development. It’s better to pay more and get a tight product that will serve you for years than something cheap but nearly outdated upon release. It’s better to have it aligned with the quirks of your industry than desperately find workarounds.
Should you really trust in DDD?
If you’re skeptical, that’s okay. This acronym might be just a new fancy word used to sell you stuff you don’t really need. However, it’s all about the difference in approaching how we design apps for your business.
There are two layers of Domain Driven Design: conceptual and practical. The conceptual layer is what we explained above. It’s about designing your app, not after some general template, but with its original purpose in mind. The practical layer, however, is about semantics. Because in order to understand you and make our software work for you, we need to use the same language.
Let’s say we are asked to make software for a logistics company. We could take some existing piece of code for data management and rewrite it so it’s now gathering data about when every parcel comes in and out.
But, you also want to know which driver gets what cargo where and when. So we take another template and edit it to make something of a real-time tracker. But these two don’t get together very well. Because in the first one, parcels are called PARCELS, and in the second one, they are under CARGO. A minor problem, you may think, but it could cause a mistake, and it’ll take time to get used to it for the new guy at the office.
DDD exists to avoid such discrepancies. It enables simple communication between everyone: you and our software house, you and your clients, you and your team, and between each of your teams. If everyone uses the same language, everything becomes so much easier. Not only because you’ll make fewer mistakes, but also because different systems now can be easily integrated together.
We’ll even go one step further. If you keep to the Domain Driven Design, your entire company can profit both short and long term. By focusing on unifying the communication, you can track down little problems that you weren’t even aware of. Little invisible problems that made you do your thing slower and with more effort. Moreover, with DDD you can also determine what already works well in your company. This will allow you to properly balance the efforts to develop in both successful and less successful areas.
It’s important to note, however, that your business model does not have to be framed in DDD. You don’t have to enforce a change in the way of thinking if everything works just fine. If your model is naturally and completely described through CRUD (Create, Read, Update, and Delete), it’s absolutely enough. What’s important is to keep the model aligned with your domain at all times.
So what’s so special about it? Why doesn’t everyone use DDD?
DDD is about achieving ubiquity. It’s done by making sure that the technology and the people understand each other. But the programmers are a specific kind. We have our own ways of thinking. We like to follow patterns and have a tendency to think and speak in programming terms. It can be really hard for an ‘outsider’ to understand us.
We at fireup.pro have taken steps to deal with this challenge a long time ago, but many studios still find it hard, or don’t consider it a priority. Transforming into a DDD software house is difficult because it requires a change in your programming mindset.
To be more precise: the programmer’s view of the world often results in developing models based on “how” instead of “what” and “why”. This is because, in programming, there is little reason to resign from a working solution. If it works, why not use it? Why not save time by fitting your needs into this pattern, instead of taking the opposite way?
Well, it usually works for the developers, but it’s not optimal for your business. With this approach, the actual purpose of the code becomes a secondary issue. And once it becomes secondary, it’s easy for it to flow away further into the background. The result of such an approach is the oven you get instead of a fridge: a technical wonder that doesn’t really do what you need. We once said that DDD introduces tailor-made products in the era of mass production – you can read more about it here: fireup.pro/blog/domain-driven-design-being-the-tailor-in-the-mass-production-era.
Sometimes it’s indeed better to reinvent the wheel—because sometimes what you need isn’t a wheel, but a conveyor belt. So yes, DDD is, at the core, a fancy acronym. Still, it’s an acronym that refers to the way we achieve the business value you strive for when you ask us to create an app. It’s about the switch from “how do we make this app” to “why are we making it in the first place,” and “how will it fit into your enterprise development.”
