DDD: A Toolbox, Not a Religion

Quick takeaways

• Domain complexity matters more than technical complexity - Most projects fail not because of technical challenges, but because they don’t handle the business domain well.
• DDD is a toolbox, not a religion - You don’t need to use every pattern from Domain-Driven Design. Pick what solves your actual problems.
• Start with the domain model - Understanding how the business works is more important than designing the perfect schema.
• Avoid solving imaginary problems - Spending months on frameworks or platforms before building actual features often leads to wasted effort.
• Strategic patterns are essential for everyone - Even if you don’t use tactical DDD patterns, thinking about core domains and module boundaries matters in every project.

Introduction

In this episode, we discuss why software projects become legacy code that nobody wants to touch.

We talk about how Domain-Driven Design can help, but also why it’s often misunderstood or overused.

Instead of treating DDD as an all-or-nothing approach, we suggest to use the ideas pragmatically - picking the patterns that solve real problems in your project.

We share stories to show how focusing on domain complexity rather than technical complexity leads to better software.

Notes

• Go With the Domain ebook - our guide to applying DDD ideas in Go
• The Domain Engineer training - launching early 2026
• Domain-Driven Design (The Blue Book) by Eric Evans - the original book that introduced DDD almost 25 years ago
• Design Patterns book by Gang of Four - classic software design patterns book
• Event Storming - collaborative workshop technique for understanding domains (covered in the previous episode

Quotes

The bold assumption for today’s episode is that you can go deep into many of the ideas and they shine in complex projects, but very often you can use some more basic version of the key ideas and apply it to most projects actually.

If you are hiring specialists in many fields, the sentence ‘if you have hammer in your hand, you will see nails everywhere’ may happen. They will spend a ton of time on solving problems that may be not the problem in this company yet.

If you consider most of applications, like SaaS apps, they are usually very similar. If you change jobs, you can end up at another completely different company and use the same tech stack. It’s not much different to use the same programming language. But on the other hand, what the company does can be completely different, and this is the differentiating factor between them.

The worst thing about that is sunk cost fallacy. So you’re spending more and more time on maintaining that, losing a lot of resources, time, and nerves on maintaining that. But it’s no longer needed.

We spent many hours creating this messaging framework using generics. And in the end, we had this good interface that you can very easily publish an event, very easily subscribe to it. And the result was that it was probably the only game jam we never finished.

You should use proper technique for a proper problem. That’s it.

If you boil DDD down to one primary theme, I would say something like it’s about understanding the domain you work with and then modeling it well in the code. Whether you call it DDD or not, it’s like a mindset.

It’s kind of forcing you to think, ‘Okay, is this code really important to my business, or is it less important?’ And it can kind of affect how we are thinking about this code.

Timestamps

• 00:00:37 - Introduction
• 00:04:18 - Technical vs domain complexity
• 00:12:13 - Technology choices
• 00:16:43 - Framework trap
• 00:21:12 - What is DDD?
• 00:31:36 - Core theme of DDD
• 00:38:22 - Context matters
• 00:43:01 - Domain model
• 00:52:00 - Wrap up

Transcript

Miłosz [00:00:37]: Hello, I am Miłosz.

Robert [00:00:38]: And I’m Robert. And this is No Silver Bullet Podcast, where we discuss mindful backend engineering. In this show, we share takes on software engineering that will help you to grow into principal engineer level.

Miłosz [00:00:51]: Let’s talk about the usual arc of a software project.

Miłosz [00:00:55]: So first we have the kickoff, and now we have high hopes for good design and this product will be great and everything is fine. This time we’ll do it. Right. Yeah. And then we work on it for some time. Then we deploy it to production. Everything is great. And suddenly it becomes a legacy project no one wants to touch. Did you ever see this happen?

Robert [00:01:20]: Every time. Okay, not every time, but yeah, it’s very often the case.

Miłosz [00:01:27]: So it’s interesting, right? Why does it happen? Why every project ends up as this big ball of mud no one wants to work with.

Miłosz [00:01:40]: And the first version works quite well. We come up with something, it’s pretty much what we wanted, that’s fine.

Miłosz [00:01:48]: And then new features come in and very often they are quite different than what the software did in the first place. Right?

Miłosz [00:01:59]: So we need to change the design. But very often there is not enough time or developers are lazy or they don’t feel like it, whatever. But they don’t remodel everything to fit the new design. Instead, we add some workarounds or hacks and it works pretty well.

Miłosz [00:02:20]: For a while, except that maybe some bugs, maybe some unusual behaviors. And we repeat it over and over, over months or years. And then we arrive at the state that we are afraid to touch the codebase. Is there a way to fix it?

Robert [00:02:39]: Oh. It. Wouldn’t be surprising to say that it’s a problem that software always had. So probably there are some magic techniques that are trying to solve this problem. One of the most popular, let’s say, tools or techniques that are trying to approach that is domain-driven design. What?

Robert [00:03:00]: If you heard about Domain Driven Design, you probably also noticed that for some reason it’s not the default way of many teams to work. From one side we have some solution, from other side probably didn’t solve all the issues that we have.

Miłosz [00:03:16]: And it’s also sometimes confusing; sometimes it seems like something you would use only for enterprise projects, but actually it worked for us before. So we like talking about it and sharing the ideas.

Robert [00:03:29]: And look how people are surprised sometimes to hear that it worked for us because many people tried to use domain-driven design and it introduced more mass for them. Or maybe they worked in a project when somebody tried to use domain-driven design and it’s the worst experience that they have. Interesting.

Miłosz [00:03:45]: Mm.

Miłosz [00:03:47]: So the bold assumptions for today’s episode are that you can go deep into many of the ideas and they shine in complex projects, but very often you can use some more basic version of the key ideas of it and apply it to most projects actually.

Robert [00:04:06]: So— In other words, in this episode, we will cover How to not use domain-driven design, but some part of domain-driven design and how to make them useful in your projects.

Miłosz [00:04:18]: First, let’s think about what is difficult about building software.

Miłosz [00:04:24]: So let’s consider someone wants to start. and they want to learn some programming language right, what would you recommend them to learn?

Robert [00:04:34]: Maybe not, why, what I would recommend, but what people are using.

Miłosz [00:04:37]: Maybe it was a default, like us were here.

Robert [00:04:40]: So. They probably need some programming language, right? Yeah. Kubernetes, OOP design patterns.

Miłosz [00:04:48]: There are some frameworks, some good practices, some algorithms, maybe data structures, stuff like that.

Robert [00:04:55]: Useful stuff that you are using on interviews, in other words. Exactly. And it’s actually, I think, pretty interesting that a lot of learnings nowadays is focused around things that are useful for interviews, but on the other side they are not that relevant when you are working in a job. And I would say that it’s even worse because you are solving problems that normally you should not solve in the problems that you are working like.

Robert [00:05:23]: You should probably not implement your own databases and you implement binary trees because most graphics have that out of the box.

Miłosz [00:05:31]: But at the same time, if this person wants to learn, wants to join a company, they probably need to learn some computer science theory, like what is big O notation. How to write optimized algorithms for sorting, how to create data structures, stuff like that.

Robert [00:05:52]: It’s useful.

Miłosz [00:05:54]: Yeah, it is. And it’s often what you need to know to join a company. But my question is, is it enough to ship good software?

Robert [00:06:03]: Well, I would say that it’s not enough, and probably it’s even not needed, because well, we are people who are self-taught, so we’ve been learning programming ourselves, and we’ve been shipping multiple projects without that, basically, and many people were using that. They were maybe not perfect, but for the other side, they worked.

Miłosz [00:06:27]: Yeah, so I would say it’s like half of the skills you need.

Miłosz [00:06:32]: And it’s useful, it’s needed. It’s often what we focus on. But there’s also the other half of stuff you need— to ship good software. So what we discussed so far is the technical complexity, right? So making software fast and scalable, and optimizing memory usage.

Miłosz [00:06:54]: Stuff like this.

Robert [00:06:55]: Probably we can put it into the bucket of software engineering. So this is this hard part. Maybe not hard, but this. Yeah, this low-level part maybe. Yeah.

Miłosz [00:07:06]: The coding part.

Miłosz [00:07:09]: And the other half, how would you call it?

Robert [00:07:14]: So if you are working with product, probably product engineering.

Miłosz [00:07:18]: Yeah. So the product or domain challenges. So basically figuring out how the thing should work and what should it do.

Robert [00:07:29]: So this product engineering or those domain challenges, it’s less about those technical parts, but rather thinking.

Robert [00:07:42]: How to tackle complexity, how this feature should work, maybe even thinking if it will be useful. Because if you know if something is not useful, you can remove some functionality and decrease complexity with that.

Robert [00:07:58]: It’s also this: less priced part, let’s say, and that it’s connected to communicating to people.

Robert [00:08:06]: Yeah, figuring out together what you want to build.

Miłosz [00:08:11]: Maybe also talking to your users?

Robert [00:08:13]: I think it’s also partly related to some long-term maintenance. So it’s, I would say, partially part of the software engineering, but I think it’s often lost somewhere because, when you have software that is not that maintainable from other side, it’s also challenging. And I would say that a lot of people that have this enduring mindset, they like challenges. So if software is complicated, it’s great because we have a lot of challenges there to solve.

Miłosz [00:08:45]: Yeah, the technical parts are very interesting to solve.

Miłosz [00:08:49]: We like puzzles. At least I know I like them too. And the technical parts often have a very specific answer to them. Mm-hmm.

Miłosz [00:09:01]: For example, we can have an SQL query, you can benchmark it, and then you can come up with a faster query. And it’s very easy to compare if it takes 2 seconds or 10 milliseconds and it feels great to have this measurable progress. But for many businesses, it’s not really critical at all. If your website handles a request in 50 or 70 milliseconds— or whatever it is— usually not a huge difference, except for the first page load, which is critical. But for many web applications, saving some data takes one second longer or shorter; it’s not a huge deal and probably not worth spending days on.

Miłosz [00:09:52]: coding on.

Robert [00:09:53]: As long as cost is not the important part, but again, it’s also some subset of products. For many products, it’s not that important at the end.

Miłosz [00:10:03]: Exactly.

Miłosz [00:10:05]: But for most businesses, the hard part is taking the problem domain they need to solve and representing this in code.

Miłosz [00:10:17]: Especially if the problem domain itself is complex.

Miłosz [00:10:23]: And usually the real world is messy in itself. Right. So we have no easy way to compare if something works or not, like with the technical parts. We often need to experiment, see if something sticks, see how users use it.

Robert [00:10:47]: Basically, the feedback loop is much, much longer and it’s not that obvious. Like you said with SQL query, it’s easy to measure if SQL query is faster or not. But obviously you can measure some customer satisfaction or some feature, but it’s more indirect and it’s usually taking a bit longer to get back to you. And it’s also a bit harder to understand sometimes how it’s happening because you can change some functionality. And notice that, okay, some behavior changed, but sometimes you may have that many changes around it—so it’s hard to judge if it’s because of it, actually.

Miłosz [00:11:28]: Yeah, so it’s much more vague. And if you consider most of applications, like SaaS apps, they are usually very similar. If you change jobs, let’s say you used to work on web application using Go and TypeScript.

Miłosz [00:11:50]: You can end up at another completely different company and use the same tech stack. It’s not much different to use the same programming language.

Miłosz [00:12:00]: Same framework, basically, protocols, databases are very similar. They don’t change much, but on the other hand, what the company does can be completely different, and this is the No.

Miłosz [00:12:13]: the differentiating factor between them. It’s sometimes funny how companies try to make their technical choices something that makes them distinct. So I don’t know if you remember— About 10 years ago, there was this hype on MongoDB, for example. Oh yeah.

Miłosz [00:12:32]: And some companies were very open about it.

Robert [00:12:39]: Proud. So when you’ve been sending CVs and it was the job posting, it was ‘Yes, we are using MongoDB. Yes, we are web-scale, but of course, it did not really matter in the end. It’s so absurd. But it’s also interesting because during that time, some people were saying that it’s absurd, but from other sites, many people were following that and saying, ‘Yeah, it’s so great.’ You’re using MongoDB, your web scales.

Robert [00:13:08]: Let’s see what we’ll see 10 years.

Miłosz [00:13:12]: You can just as well use JSON columns in Postgres and achieve pretty much the same thing, except for some differences in very specific cases.

Robert [00:13:22]: Or losing changes because of inconsistencies between nodes.

Miłosz [00:13:28]: Yeah, but basically, if you take two companies that do the same thing and one uses one database and the other MongoDB, whatever.

Miłosz [00:13:39]: It probably won’t impact that much the end result. How well they do in business, how many users they have, how good the product is.

Miłosz [00:13:49]: There’s a lot more factors in it.

Robert [00:13:52]: Okay. In other words, we can say that many companies, many people maybe solve on the wrong thing because when starting your project, they’re thinking, ‘Okay, this time we’ll use this framework, this database.’

Miłosz [00:14:06]: Yeah, very different this time.

Robert [00:14:08]: Yeah, yeah.

Robert [00:14:10]: This time everything will be great. And again, we are in the cycle of starting in the greenfield and ending up with legacy, like: It was done five years ago, 10 years ago. So probably.

Robert [00:14:28]: The technology that we’re using— the framework, database, maybe not the most important indicator if project is successful or not, and by ‘successful’ I mean multiple things. So, if it’s maintainable, if it has users, if it makes money— probably from perspective of developers, the maintenance is the most important part. But again, it’s not the only thing.

Miłosz [00:14:54]: Yeah, but we treated that as something that’s a core thing we need to solve. Sometimes. Right.

Miłosz [00:15:03]: I remember some companies with the idea that we will dedicate top talent to this core platform framework— or something— and once we solve it, then adding new features and apps to it will be trivial. Just hire anyone who’s able to code in this language, and they will just use this great framework to implement a new feature in one day.

Miłosz [00:15:34]: I don’t know where this idea comes from, but I think it’s quite common.

Robert [00:15:40]: And I think one part of the problem may be that if you are hiring specialists in many fields, the sentence ‘if you have hammer in your hand, you will see nails everywhere’ may happen. I mean, if you find hiring specialists from multiple areas, they will spend a ton of time on solving solving problems that may be not the problem in this company yet. So, for example, this startup and it’s starting. They don’t have scale yet. And probably it could be run on a single VM. And later, you have, for example, some Kubernetes specialists. So what they can do, they can create multiple Kubernetes clusters for multiple environments and later serve. Requests per second and even 10 requests per second. It’s like nothing. You can do it with a single VM, but it’s not for free. Obviously, you are using your top talents, but for solving problems that are not important.

Miłosz [00:16:43]: And I remember myself falling into this trap, probably multiple times. But one story that I remember very well is how I used to run some game jams with friends, just making game in two days, right? And one time we wanted to create a story-driven game with a lot of dialogues, so you can choose dialogue options and it leads you to a different part of the game. Somehow we came up with the idea that we will do it event-driven. So each option will be an event that sends and triggers something. We had this idea that, now, this would be a lot of events, which will be hard to manage. So we will need this even during the framework. So, if only we get this framework right, all that’s left is to implement the dialogues.

Miłosz [00:17:30]: That would be it. So we spent many hours creating this messaging framework using generics.

Miłosz [00:17:40]: C# and I didn’t work very well. So it was super fun to come up with it. And in the end, we had this good interface that, you know, we just, you can very easily publish an event. Very easily subscribe to it. And the result was that it was probably the only game jam we never finished. We had this technical solution, but we didn’t progress with the game at all.

Robert [00:18:05]: So in other words, you are not the best specialist to be hired to build event-driven games. Exactly. Exactly.

Robert [00:18:12]: I can create a framework for you.

Miłosz [00:18:14]: I think it shows. It’s like a very condensed, you know. Scenario that I think happens on bigger scale as well, and I don’t even know where it comes from, but somehow we tend to think, if only we can create this framework first, and everything will be easy.

Robert [00:18:36]: And sometimes, if you succeed in creating this framework or whatever it is, this prerequisite, and you’re starting to rework on the things that matter.

Robert [00:18:47]: You’re starting to notice that, okay, actually, it’s totally not needed.

Robert [00:18:52]: We just spent two months on that. And you know what’s the worst thing? The worst thing about that is sunk cost fallacy. So you’re spending more and more time on maintaining that, losing a lot of resources, time, and nerves on maintaining that. But it’s no longer needed.

Miłosz [00:19:12]: Yeah, and you don’t want to get rid of it because you invested so much time. Yes, I think we’ve seen many examples like that, right? I think it’s very common when you have a platform team in a company that is supposed to make all teams work together. Very similar ways this is exactly the idea of having one great system that you just add tiny pieces to, and of course it makes sense for a bigger company. But sometimes you can get go too far. I remember one time we had the platform team create service mesh for developers. To use it, you have service discovery so you can communicate between services using just service names. Sounds great, and they spent half a year working on it. But first of all, no one asked for it.

Miłosz [00:20:07]: And we really didn’t have any use for it later. It just looked great on paper.

Robert [00:20:13]: I think we even mentioned that. Yeah, but maybe we don’t need that because we already are doing it in Middleware.

Miłosz [00:20:21]: Maybe if you have five services, maybe you can just call it with the URL of Kubernetes and wow, it’s enough.

Robert [00:20:29]: Yeah, and all the cross-cutting concerns could just handle it with common library and middlewares. That’s it. It’s probably again, it depends on context. If you have a super complex project with multiple programming languages, maybe. But in this case, we just have one technology there and it solved the problem already.

Miłosz [00:20:52]: So this is all the first part, the technical part you mentioned. Sometimes it’s easier than the domain part, the product part.

Robert [00:21:00]: And it’s very often. You can move it between projects as you said earlier. So it can be very similar across and you don’t need to reinvent the wheel basically. So we already know that this technical part is very often similar between the projects and the thing that is different is the domain.

Robert [00:21:24]: part of the project. And we already mentioned once domain-driven design, that it’s supposed to be helping us with this.

Robert [00:21:33]: Think that is unique to our company. and many of you, maybe heard about this earlier, but it’s not.

Robert [00:21:43]: wide load up. do you have some ideas why it’s like that? and actually, what the point of indesign at the first point?

Miłosz [00:21:51]: maybe it’s even difficult to define what the approach really is in a very short description. and i remember before i knew about the dd. i think my first contact was when my manager wanted to have the entire team join the training for off-domain design.

Miłosz [00:22:17]: and they sent me over like a pdf description of it with lots of details what the training is about and i remember reading through the document.

Miłosz [00:22:29]: and at the end i was like, what is this? i have no idea. How is this supposed to help me with my day-to-day work? I just completely had no idea what.

Robert [00:22:41]: What’s the idea? So it was more covering some non-technical things and at this point you were thinking, ‘Okay, it doesn’t matter’ or ‘it was not sold properly,’ let’s say.

Miłosz [00:22:51]: Yeah, I think it was missing the ‘why.’ And I think also DDD has a lot of unique names or terminology that you didn’t hear before. So if someone tells you, you will learn about bounded contexts. You’re like, ‘What?’

Robert [00:23:10]: I know about design patterns, but what is this? Or maybe aggregate and, oh, okay, so I can aggregate some data.

Robert [00:23:20]: Okay, another reason why it’s not that widely adopted, and maybe now it’s very often missing interpret. It’s also the reason that point-driven design is out there already for a pretty long time. So the blue book, so the book that was introduced it. Introducing Domain Driven Design was released almost 25 years ago and the programming world 25 years ago was totally, totally different.

Miłosz [00:23:54]: And it was based on years of experience from Eric Evans, so I guess you can say it was about software written in the 90s. So it sounds like a different era today, kind of.

Miłosz [00:24:09]: But on the other hand, you can still hear about the DD a lot. Maybe not every company practices it, but there are conferences and books dedicated to it.

Miłosz [00:24:23]: So, probably suggest to you that there are many good ideas. That’s how evolution works. Good ideas tend to survive for longer.

Robert [00:24:32]: Unfortunately, there’s also a side that many good ideas are misunderstood with time. So some good ideas are useful at the beginning. More people are trying to adopt them. But unfortunately, if those good ideas are not straightforward, but require bigger investment to understand them. Some people tend to get shortcuts and not use them as intended or use them everywhere and it’s quick ending up with some kind of caricature of some techniques, tools. So in other words, many techniques or tools at the beginning were good ideas and were solving some problems, but with time, when people were adopting that, they were starting to adopt some caricature of this technique and it’s often started to do more harm than good. It was visible in discussions that we have in many teams that some people have seen domain-driven design in some projects, but it wasn’t really domain-driven design what they see.

Robert [00:25:38]: They’ve seen some overengineering, maybe, just doing it for the sake of doing it. Yeah, so using it in places when it wasn’t needed. So it was just too simple application maybe to use that. And to make it worse, it wasn’t used in there. Right way, because the initial investment was just a big end. People tend to not spend enough time to learn something and, Well, it’s easy to imagine that after 25 years, many, many of projects like that was created and it created a lot of bad PR.

Miłosz [00:26:17]: And you can hear people saying, ‘I don’t want to work like this ever again,’ because it was a disaster. It was a super complex project that was made overcomplicated.

Robert [00:26:28]: The similar situation is also, for example, with clean architecture, when we sometimes hear that, ‘ah, no, clean architecture doesn’t work,’ and later we hear about seven layers and.

Miłosz [00:26:39]: Yes, but on the other hand, if you read the introduction to the Global. I think the core ideas are still very relevant. The introduction describes the state of most software projects. How they get stuck, what are the issues. And now it’s almost 25 years later, everything pretty much in the same spot.

Miłosz [00:27:08]: Sense. We got better with frameworks and some technical stuff, but the core idea of working with people on the product.

Miłosz [00:27:21]: Not that much different.

Robert [00:27:22]: Are you suggesting that we are reinventing the wheel in software every 10 years? No, it’s not possible. And it’s 25 years during. since releasing the book. I can imagine that we reinvented the wheel at least twice since that time.

Miłosz [00:27:41]: microservices and then ditched them. Twice. It was a full cycle. For example, in the Eric Evans book, he says that XML would be a promising technology to communicate between services. Yeah, it’s something fresh to send XML over RPC. Yeah, so since then we probably reinvented this idea a few times. We’ve.

Miłosz [00:28:10]: microservices and protocol buffers over gRPC. It’s still the same. Coming back to the question why it’s difficult to understand what DDD is, it’s very broad. It’s like an entire book of many, many ideas. and from design patterns to communication between teams. So it’s very difficult to say what doing GDD means. It’s just very broad method.

Robert [00:28:43]: We can also say that it may be philosophical in some way. Hmm, hmm.

Miłosz [00:28:48]: Yeah, and you can interpret the patterns in many ways.

Robert [00:28:54]: The domain part of projects can differ between projects. So it’s hard to give one solution that fits all. So it’s probably because of that, but it’s also creating a lot of space to interpret things. Hmm. It remains one thing. If you are with us for longer, you maybe already know that some time ago we decided to leave our daily jobs. And now we are doing our own business. But it’s not the first time when we’ve been trying to do that. And we’ve been trying to do it multiple times earlier. But I think. One thing that probably didn’t allow us to succeed earlier was that we didn’t spend enough time to understand actually how to run business.

Robert [00:29:43]: How it actually worked that you’re running a successful business. So maybe you had some idea that if you would like to have a successful business, you need to sell things. Uh, do some marketing, do some sales, and earn more than you are spending.

Miłosz [00:29:58]: Easy, but just— you just need to read one business book, yeah, which is called ‘Business’ and explains how to do business.

Robert [00:30:07]: Yeah, but in practice, it’s not that simple and it’s more sophisticated, let’s say. And if you will not spend enough time to understand how it works deeper.

Robert [00:30:20]: The chance that your business will fail is much, much higher. I think the statistics are like in five years, 50% of businesses are failing, and in terms of startups, it’s probably 80% in Twitter or something like that. So it’s a crazy number actually.

Robert [00:30:38]: And on the other side, it’s something that you can learn, but you need to spend a bit more time to learn those principles and to not do. Caricature of your business.

Miłosz [00:30:50]: It’s similar a bit to DDD. It’s a very broad term and a general approach to solving and you need to learn many patterns.

Robert [00:31:00]: And it’s hard to give one advice that will fit all cases. But it’s doable, but you need to spend some time and keep in mind that many, many, many people are not doing this exercise and are later surprised that it doesn’t work.

Robert [00:31:18]: Like with DDD, you can also see that many people are saying that running business is super hard.

Robert [00:31:23]: So I would say that it’s hard, but I think it’s also not. That hard that people think. It’s just about knowing the principles and spending enough time on it.

Miłosz [00:31:36]: Right, so if you were to boil down DDD to one primary theme, I would say something like it’s about understanding the domain you work with and then modeling it well in the code. Whether you call it DDD or not, it’s like a mindset. More than patterns, maybe?

Robert [00:31:57]: In other words, you should always do that. I mean, if somebody will tell you that, okay, you should not think about the domain, what problems you are solving in your software and how you are writing in an account like it sounds crazy.

Miłosz [00:32:12]: Yeah, it’s like you’re deciding. Yeah, I will create a website. I just don’t know which one. So it sounds like you do something for the sake of learning the technology, which is fine. Sure. But if you want to create a product, it’s not really helpful.

Robert [00:32:32]: My observation is actually that dark.

Robert [00:32:37]: Two kinds of people that are often visible in the area of techniques like domain-driven design, architecture, take anything.

Robert [00:32:46]: There are two comps that are totally opposites. One comp is saying that you should always use that. Because it’s great, etc. And the second is you should never use it. That is the worst idea in the world. And I think it’s pretty interesting that even if they are opposite, they have many in common because they are extreme in some way.

Miłosz [00:33:06]: So they treat it more like kind of religion rather than something you want to use to deliver a product.

Robert [00:33:17]: And in practice, probably you should be somewhere in the middle.

Robert [00:33:23]: It may sound obvious, but you should use proper technique for a proper problem.

Robert [00:33:29]: That’s it.

Robert [00:33:31]: It’s important when you see some religious people about techniques or tools that are against them or love to use it always that it’s the same coin, but just other sides of it.

Robert [00:33:46]: I think it— gets into one thing that you should watch out to not use any techniques or tools like DDD just for sake of using it. So you should identify the problems that you have and use the right tools for that. And the Winterwind design have couple tools that you can take out of that like a tool from a toolbox and just use what you need from that.

Miłosz [00:34:12]: There’s probably no project that will use every pattern described in the book.

Robert [00:34:16]: Yes, but probably you agree that every project should use some parts of domain-driven design. So it may sound controversial, but it’s getting into a point that you may be using some parts of domain-driven design. Even without realizing that. It may be because of reinventing the wheel. Again, it’s probably easier to just see that, okay, you have some tools like that, but many of them, some people just can find them, yeah, probably except for very trivial projects, but we don’t care about them here.

Miłosz [00:34:51]: Like, if you create something that’s very trivial and doesn’t need any kind of design and architecture, and you probably don’t need to figure out how to do it better.

Miłosz [00:35:05]: So we don’t worry about this here.

Miłosz [00:35:09]: Maybe also something very technical like Linux kernel. I don’t know. But probably also there should be at least one idea from DDD that applies there. Maybe value object.

Miłosz [00:35:21]: Yeah, but in general.

Miłosz [00:35:24]: If you boil DDD down to some very key ideas, I think you should be able to use them if you know what you’re looking for.

Robert [00:35:34]: I think it’s a similar situation like with the book Design Patterns. So pretty old one. I don’t remember actually how many years. It’s older than DDD. But I think 96 or 97. So still, pretty old book, but still pretty relevant and many of us may be using patterns from this book. Even without knowing that those are patterns from this book, because it was used by somebody else and we learn those patterns by replicating them. But still. We may be missing some of the context maybe of them. And if we read that, maybe we could understand them a bit more and apply them in the better situations also.

Miłosz [00:36:15]: I remember there was a joke or people making fun of people in interviews. When asked about design patterns, they will tell something like, ‘Oh, yeah.’ There’s the singleton, and that’s it. But that’s also kind of the point. You know, there’s an entire book, and doesn’t mean you need to know all the patterns and use them all in a project— even if you learn about some, like maybe you can use a strategy here or decorator in another place. I think it’s still a good result. You don’t need to force them and rewrite your entire project to use, I don’t know, abstract factory method or something.

Robert [00:37:00]: It’s always about identifying some problem that is really a problem, and not solving.

Robert [00:37:08]: Some imaginary problems. Yeah.

Miłosz [00:37:10]: Especially if you force the patterns. I think that’s the worst thing that can happen because it just leads to overengineering. You just read the book and you like the ideas, so you use them everywhere in your next projects and of course they don’t apply to all of them.

Robert [00:37:27]: And I think it. It plays nicely with a couple of things that we covered in the previous episode that we’ve mentioned: that being a principal engineer doesn’t mean that you’re forcing to use some patterns. You should instead be able to convince people what value those patterns give and and convincing them that it’s worth using some patterns there. Hmm. And at the end of the day, it’s also a matter of solving your problems, not imaginary problems.

Miłosz [00:37:59]: There is no one solution to suggest. Because there are so many factors in play, like the size of your team. If you are a 20-person team in a corporation, a developer working on open source software, or maybe you are a five-person startup, you will probably use a very different approach to software.

Robert [00:38:22]: And also, what’s the timeline for the project? Because if you are in a startup that you’re starving for, if you don’t know if you will survive half a year, and you’re doing refactoring, it’s probably not the best idea, but I mean, it depends, obviously, but it’s again going back to solving real problems that you have. So, if you are a startup that has a half year of runaway and you’re fighting for survival, you should choose your fight wisely, basically, and not put maybe refactor some code. That you didn’t touch for a year and put design patterns there. But maybe you have some part of the application that, for example, you are doing a pivot now and you need to— it quickly, but you’re wasting a ton of time to modify this code, maybe doing this refactoring and putting those design patterns may be good at the other, even if you’re fighting for survival.

Robert [00:39:26]: Because maybe it may allow you to build this new functionality or do this pivot within this time that you have left.

Miłosz [00:39:33]: Have some idea that this project will be for you longer. You probably need some better maintenance here. But but maybe some some areas are more less important. Maybe you will get rid of them in two months if it doesn’t work out. But because it’s sometimes difficult to decide.

Miłosz [00:39:57]: This might be a bit controversial, maybe, but I think you don’t need to go all in. Most of the patterns from DDD you could decide to use them in a more, let’s say, shallow version, other than deep version. So you basically think of the the first principles, the big idea behind the pattern. You don’t need to implement all of it and still get some good results. Because you often don’t know if the project you work on will be with you for longer, or maybe it’s just a prototype.

Miłosz [00:40:33]: But I think there’s a balance between having some very scrappy code and something that’s very enterprising. While design software.

Robert [00:40:44]: It’s actually an interesting thing because it’s one of the things that Domain Driven Design covers with core and supporting domains.

Robert [00:40:56]: It’s kind of forcing you to think, ‘Okay, is this code really important to my business, or is it less important?’ And it can kind of affect how we are thinking about this code.

Robert [00:41:09]: I know that many people like consistency in the code, like, ‘Okay, let’s do.’ Something in the consistent way everywhere. End. It may sound like a decent idea, let’s say, but it may be also dangerous because you at some point start to over-engineer some parts because some parts of the application are more important, more often touched, more complicated, and some are simpler. You may just lose a lot of time for maintaining this consistency for sake of nothing. Basically.

Miłosz [00:41:44]: So this episode is more like an introduction, but in the next episodes we want to cover more patterns from both shallow and deep end, so you can better decide what to use.

Robert [00:41:58]: But I think we should put big emphasis on the thing that people are very often missing. So the strategic part, because Tactical patterns— those strategic domain-driven design— are the patterns that are not that much about how you write the code, but it’s more about strategic thinking, like how the modules are interacting, how modules are split. Very often cross-team collaboration.

Robert [00:42:28]: How important are multiple parts of the code? And what’s interesting, everything what I just said, I think you should probably think about that in any project that you are doing. You’re using domain-driven design or not. It’s cool to have some tools that are helping you to do that, and some frameworks— let’s say it’s not a framework, but some way of thinking how to approach this. And from other side, you have technical patterns that you’re using in the code, and those ones are not always needed. And you don’t need to always apply them.

Miłosz [00:43:01]: So we won’t be diving deep into patterns today, but let’s look at the core idea of DDD.

Miłosz [00:43:12]: The domain model or model-driven design or knowledge crunching, as it’s specified by the book. What is it about?

Robert [00:43:23]: There’s one thing in multiple projects that is a bit like running business, like we said earlier. So it’s obvious that you should earn more money than you are spending. so you have a successful business. In software, it’s a matter of understanding what kind of problem you are solving and how it should work.

Robert [00:43:45]: It makes all of us like, yeah, we are starting a project. We should understand how it works and how we should implement that. From other sites It’s not happening.

Miłosz [00:43:59]: yeah because sometimes the business is complex by itself and even for simpler ones like consider e-commerce seems like a simple domain it’s just people People buy products and that’s it. But if you dive deeper, there’s capturing payments and delivering the products and getting the inventory somehow. So it’s more complex than it seems.

Robert [00:44:24]: How it looks in practice? People are thinking, ‘Oh, okay, it’s simple.’ We know what to do. Let’s go to implement that. Exactly. Two years later.

Miłosz [00:44:33]: Consider, if you wanted to to open an online shop.

Miłosz [00:44:38]: Oh. If you ask a software developer, they will probably tell you, ‘Yeah, you just need to host this WordPress website. With an e-commerce plugin and you’re done.’

Robert [00:44:52]: I think many software developers will say, ‘No, no, we need to implement it from scratch.’

Miłosz [00:44:57]: Oh yeah, that’s even better. But my point is, they probably won’t think about that— that you need to. Order the inventory from somewhere, store it somewhere, and then somehow send it out to people, which is the hard part of the business and your software probably needs to work with it somehow.

Robert [00:45:16]: It actually works nicely with this part of strategic patterns of domain-driven design when we are considering what’s our core domain and what’s the value for our company.

Miłosz [00:45:27]: And many projects are much, much more complex than e-commerce. If you consider accounting, for example, you can get into some very very specific edge cases depending on the country and if you do do it globally, then it’s yeah, it’s crazy amount of knowledge you need to understand and to implement.

Miłosz [00:45:48]: Complexity in those projects doesn’t really come from the technical challenges, but from the business itself. It’s just complex to run this kind of business, so the software becomes also complex.

Robert [00:46:03]: So, in other words, you have multiple dimensions, complexity dimensions, let’s say, to this product, and you can add more and more and more. So, for example, you’re starting with one country. Right. We need to scale globally. Okay. We need to support multiple countries, multiple continents. Great. Later, we need to support multiple types of product. So it can have multiple tax rates and multiple rules. It’s getting more and more and more complex.

Miłosz [00:46:28]: And it’s always complex even before you introduce any kind of technical challenges. Just not considering software at all. This is already complicated.

Miłosz [00:46:39]: So you want to model it well in the code, so at least you don’t need to deal with the additional complexity.

Robert [00:46:51]: And to make it worse, often the initial idea is also changing with the time. So I have two good examples of the companies that were like that. So Netflix.

Robert [00:47:01]: Maybe many of you know that Netflix at the beginning was an extreme platform. At the beginning they were just renting DVDs. So it’s interesting how it changed over time, how they were making business, and probably how much it changed how they’re operating. The other interesting business that changed over time is Instagram. Instagram wasn’t this kind of social media platform that you know now; it was more checking location applications. So I guess you were able to send people information like, ‘Hey, I’m here’ or something like that, not share pictures.

Miłosz [00:47:40]: Yeah. And so imagine in both cases.

Miłosz [00:47:45]: At some point, developers complained that the requirements weren’t clear. We didn’t know this component would become this thing it is now. Of course, it wasn’t clear because no one knew about it back then and they had to adapt somehow.

Robert [00:48:00]: Those examples were more extreme, let’s say, but most companies are changing their initial assumptions pretty much, so it’s also adding this complexity there.

Robert [00:48:14]: I also like example of the cyberpunk game that the cars are horses from Witcher 3 because they’re using the same game engine.

Miłosz [00:48:25]: Yeah, so that goes back to the discussion of evolving software. The first version is usually simple, right? Everything works fine. But then someone tells you, actually, we’re not renting DVDs. We’re going to be streaming videos.

Miłosz [00:48:42]: And at this point, you have to change your software to a completely different model sometimes.

Miłosz [00:48:52]: It’s great if you could do it easily, if you don’t need to spend one year to rebuild everything. What helps is also what we mentioned in the last episode about developers working directly with domain experts.

Robert [00:49:06]: So even if it’s a bit controversial, so we’ve seen how it can change things and again affect how you are implementing things.

Miłosz [00:49:17]: So we don’t need a product owner or product manager acting as a proxy?

Robert [00:49:22]: Always, because sometimes it makes sense, but sometimes it makes sense to just go direct.

Miłosz [00:49:27]: But the idea of the domain model is to create a model that represents the problem domain as well as you can at the moment.

Miłosz [00:49:37]: Developers can understand how it works, the more information they get from the people who work directly with the business. The better. The model doesn’t need to be physical, so it’s not a document or diagrams or anything else, although it helps, but it’s more abstract. It’s about understanding how it should work. And.

Miłosz [00:50:03]: The ultimate artifact is the code.

Robert [00:50:06]: And it also doesn’t need to cover everything. So I always like to compare this model part to a map. So map is not a perfect representation of real world, but it’s a useful representation of the real world. So you can look on the map and see the details that you care about and do the job that you need.

Miłosz [00:50:28]: And it’s also not a data model, which is a common misconception.

Miłosz [00:50:35]: Very often in software you can see models used for both the domain logic and some storage, for example, or transport.

Miłosz [00:50:49]: For developers this is unnatural.

Miłosz [00:50:52]: No. thing to do treat them as the same so we often start implementation with database schema, for example, because it feels natural to think of storage.

Miłosz [00:51:03]: But here we think about the more abstract domain model, how the thing works, what behaviors it has.

Robert [00:51:11]: So this is pretty big part. Paradigm shift and it’s also not consistent with how we’ve been learning earlier. So this is also the theme that was pretty common in the last two episodes. But how we are learning to code is very far away from the real world. And we are not prepared actually to work in the companies. And later it’s ending up with the.

Robert [00:51:37]: golden cage concept from the previous episode. Getting out of that is not simple, but I think it’s mandatory if you would like to be successful and survive on the tough market and work in the better places.

Miłosz [00:51:52]: Another tool from the previous episode is event storming, which is also closely related to figuring out the domain.

Robert [00:52:01]: So today we’re more focusing focusing on giving you some introduction.

Robert [00:52:09]: To— Maybe not Domain Driven Design really, but some parts of Domain Driven Design that we’ve been using in the project. Sometimes we’ll name it Domain Driven Design, sometimes not, because again, its patterns are secondary. I think it’s more important to focus on problems, not on the patterns, because when you are focusing on patterns, you are just with this hammer in your hand and looking for nails everywhere. So I think it’s more important to focus on problems that we’re solving and how we can do that. And yeah, this is something that we’ll be doing in the next couple episodes and it’s connected to the fact that now we are working on our new training the domain engineer and that will be available at the beginning of next year in January.

Miłosz [00:52:56]: Yeah, so in the next episodes we will look at more use cases for the strategic patterns.

Robert [00:53:02]: Yeah, so we’ll give you some more practical tools also, how to approach that.

Miłosz [00:53:08]: So let us know in the comments if you have any topics you would like to hear about. You can also check our ebook, ‘Go With the Domain,’ which is about working with domain-driven ideas.

Miłosz [00:53:22]: In Go specifically.

Robert [00:53:24]: Yeah, so we will be preparing agenda for next episode soon. So let us know on YouTube comments or Spotify comments. So read all of them and it will be. Cool to help you with some projects or problems that you have. We have many, many, many stories from projects that we’ve been working in, but we’d also love to introduce a bit more there.

Miłosz [00:53:50]: So that’s it for today.

Miłosz [00:53:53]: Subscribe to our channel so you can see the new episodes as they come.

Miłosz [00:53:59]: And hit that like button.

Robert [00:54:01]: And if you don’t want to miss when the domain engineer will be available, just Google the domain engineer and join our newsletter if you are not there. Yet. So we’ll send you an info when it will be ready. And you will also notified when new episodes will be out, because we know that sometimes notifications from multiple platforms are not sent. So when you’re in our newsletter, you are sure that you will always get the notification.

Robert [00:54:29]: Okay, so I think that’s all for today. So thank you, Miłosz, for your time.

Miłosz [00:54:33]: Thank you, Robert. See you next time.

Robert [00:54:35]: See you in two weeks. Bye-bye.