Domain-driven design – who needs that?
"Challenging? I would say it has made my life easier somehow."
Welcome to "Querverlinkt – Technik über dem Tellerrand"! After our last podcast on programming languages, we have another in-depth episode for you on our favourite topic: software development. This time it's about design concepts in software development, or more precisely, domain-driven design. A way to model complex software. Of course, this immediately raises questions: Why do we model and what does this have to do with software development and software architecture? Thomas Sinnwell and our experts, Marcel Zinnow and Michael Bub, explain. Domain-driven design, who needs that?
Have fun listening!
Thomas Sinnwell: Hello everyone! Today we are talking about Domain-driven Design. A very exciting topic. To explore the question of what exactly it is, I have invited two guests. One is Marcel Zinnow and the other is Michael Bub. Some listeners probably already know Marcel Zinnow from the podcast episode about agile software development. And Marcel is responsible for very large individual software development projects at consistec. It's nice that you're here. Please be so kind and introduce yourself.
Marcel Zinnow: Thank you Thomas! My name is Marcel Zinnow, I've been employed at consistec for 14 years now, I studied computer science at the “HTW Saarbrücken”. And as you mentioned, I've been a project manager for software development projects in the telecommunications industry for several years now.
Thomas Sinnwell: Thank you! Michael Bub is on board today, he is a software architect. It's good to have you here. Michael, be so kind and please introduce yourself as well.
Michael Bub: Thank you Thomas! My name is Michael Bub. I studied computer science at the HTW Saarbrücken. I started my professional life as a Java developer in 2007. I joined consistec in 2011, still in the Java environment, and have now been doing softwaredesign- and architecture for projects I'm involved in.
Thomas Sinnwell: Thank you very much! Let's clarify the question: what is domain-driven design? To start with, I'd like to make the following statement: Yes, it's a way of modelling software. But what does that mean? What does software modelling mean?
Michael Bub: Well, modelling ultimately means transferring something from the real world into software, I would say. We don't make software for fun, but we develop software to solve problems that arise in the real world. For example, I want to sell a product and need some software to support me. And in order to be able to solve this problem in software, I have to solve the problem in this specific domain. I have to transfer it into software. And that is what modelling tries to do. So we look at the real world and its problems and its players. A simple example, let's say I want to develop a chess programme, then I have to master the rules of chess. Then I try to put these rules into a software. So it's sort of a simplified representation of a real thing into a software. For example, let's say for my chess game that I'm programming, what a knight looks like, because the appearance doesn't matter at all for my problem solving, but it is relevant for me, for example, that it is a knight and that it has the colour white.
Thomas Sinnwell: Okay! We have to go into that a bit more. But two other questions come to mind right now: What does this have to do with software architecture or with the code?
Marcel Zinnow: On the one hand, the architecture is a guideline for software developers on how to model the software, how the software should look, how the programmers should develop the whole thing.
Thomas Sinnwell: So in terms of its structure?
Marcel Zinnow: In terms of its structure. Exactly! And on the other hand, the developers will also bring their own models, which is then part of the overall architecture. I'm thinking of data models, for example. The structure of the data is roughly specified by the architecture, which the developers must adhere to, but it is the developers who really fill in the details. The same goes for code models, sequence diagrams can be created, activity diagrams to model certain activities. The whole interaction, that's architecture or software development.
Thomas Sinnwell: If I have understood you correctly, this modelling extends into the architecture as well as into the code? Correct?
Michael Bub: That is absolutely correct. Architecture can take place on many different levels. It can be very, very coarse, this system lives on a server in some other country, so it lives somewhere else. But it can go deep down into the details as well, so that you can specify classes, hierarchies, in which relationships they stand to each other.That can describe the big picture and very specifically what is supposed to happen later in an individual software.
Thomas Sinnwell: Good! Now we're already seamlessly on the subject of software architecture. I think that at the beginning of 1990, the topic of software architecture became a sub-field of its own in computer science and was given its own space. Many clever people have already written about it. But what is software architecture about now? You've already mentioned a few things.
Michael Bub: Basically, it's about simply having a rough plan. So the word architecture or architect, you know that from building a house, for example. You don't just start building a house, you make a relatively detailed plan of what it will look like beforehand. You can't just remove a load-bearing wall, it has to be in a specific place. And it's similar in software architecture. So you look at what do I have to do, what task do I have to fulfil with this software? And here we mainly talk about non-functional requirements, i.e. what exactly the content is.
Thomas Sinnwell: And what is that?
Michael Bub: The non-functional requirement is basically the opposite of the technical logic. That's when topics come up like, I have to be able to guarantee some kind of response time. Maybe I have to use a certain technique to make the software as fast as possible. And other topics. For example, there may be a data protection issue, which has some effect on how I build a system. I have to take that into account. All these blocks that I need, that fulfil certain tasks, you try to find them in the architecture and roughly draw how they stand together in the overall system. And we also try to briefly describe how they are used. So a component offers an interface that can be used, and the rest, let's say the exact implementation, what's behind it, is uninteresting, that's not interesting for the architecture at first and is only filled with life by the developer much further down the line anyway.
Thomas Sinnwell: That means software architecture is about these non-functional requirements as well? And there was already talk of performance. I think this can be seamlessly expanded to include maintainability. That means that once software has been developed and handed over, it can be maintained and further developed by other people or by the company that created it. It's also about issues like reliability. And at the beginning you gave the example of building a house.
Michael Bub: Yes.
Thomas Sinnwell: And then the architect comes and makes a plan. Then comes the structural engineer. Then it is perhaps modified again, some wall is made a little thicker or a girder is inserted somewhere. Then it stands. That is rigid. How does software architecture fit in with agile software development? Is that a contradiction?
Marcel Zinnow: First of all, software architecture is completely independent of the agile approach. You can do software architecture as well in the waterfall model and in agile development.
Thomas Sinnwell: But how does that work in concrete terms? Because I don't make the finished architecture initially and then develop it agilely.
Marcel Zinnow: Exactly! No, the architecture is built in iterative steps, as the agile approach prescribes. This is due to the fact that requirements can change quickly. The agile approach is just as suitable for the architecture, in that when you build the architecture, you define it according to the current requirements as they are in that moment. And if the requirements change, you can then change the architecture in different intervals, different steps.
Thomas Sinnwell: But now we've reached the point where we can move on seamlessly. What exactly is domain-driven design?
Michael Bub: It's always a bit difficult to describe in one short sentence. Let's say it tries to regain something that we had in the past, at the beginning of software development, sometime in the 60s. That's when it happened, when software development first started, those were people from the technical department who had just learned how to develop software, and then they wrote the first programmes for the company. And at some point the IT department grew stronger and bigger and became its own department. And suddenly there was a strict separation between the technical experts and the people who wanted to build the software. With domain-driven design, we are now trying to bring the experts and the developers together again in order to create a common picture of what we actually want to do. That is one thing domain-driven design is trying to achieve.
Thomas Sinnwell: That is, to give the people in the technical departments at least some elementary knowledge or a concrete idea of what software development is all about, how it happens, how it is done. Because they have to use it later on and to establish the professionalism of the software developers a bit more.
Michael Bub: Exactly! So basically you try to get the programming experts in some position so that someone can competently develop what actually corresponds to reality. Because if you are honest, such a finished software is not exactly doing what it is supposed to do afterwards. It is what the people who develop it have understood it to do. And they try to be very precise and to exactly represent this behaviour of reality and to eliminate as much room for interpretation as possible.
Thomas Sinnwell: Now, technicality and technical logic, which are terms that have already been mentioned, play a very elementary role in domain-driven design. But explain to our listeners: What is your understanding or what do you mean by technicality or technical logic?
Michael Bub: Well, you could say, let's stay with the example of chess, that if I want to develop a chess game and do it domain-driven, then I have to understand the rules of chess, I have to have learned them, I have to be able to apply them to software. That means I will then have experts explain to me how it works and then, together with them, I will develop a model, for example in the form of a picture, or perhaps in writing, so that afterwards everyone has the same opinion, ah, this is how chess is played and not otherwise.
Thomas Sinnwell: What comes to my mind right now, which I think is always a source of questions, even among clients, is the concept of pattern or anti-pattern? Is there an anti-pattern here? Or what is a pattern anyway?
Michael Bub: A pattern, according to its name, is something that occurs again and again. And then there are patterns that we know from development. There's a singleton, for example, just to name one. And then there are also patterns that you come across again and again, that are used as solutions in software systems. They work, otherwise they wouldn't be used, but they tend to have a damaging effect. In other words, they are not good in the long term in some way. This can take different forms. They may be too slow, they may be difficult to maintain, they may have some kind of disadvantages. And that is then typically an anti-pattern.
Thomas Sinnwell: And what would the anti-pattern look like in domain-driven design?
Michael Bub: There are of course various conceivable problems that one could discover there. In my opinion, the worst thing is to develop a domain model that does not contain the rules of the game, so to speak. For example it contains classes that simply contain data, but which do not have any behaviour. And that is exactly the point that domain-driven design wants to prohibit. In previous projects, you can say that there is this service approach. You have these data structures, for example my chessboard and then there is some service that does something with this chessboard. So the functionality, the operation and the behaviour is strictly separated from this data. That makes it a bit difficult to keep track of everything. And if you create a real functioning domain-driven design, then you have the chessboard and the chessboard also has the operations that it is supposed to perform, for example. So the chessboard might now have this operation: make a move from a piece to a specific square. It all grows together there.
Thomas Sinnwell: Now I'd like to go into a little more detail about the domain model in Domain-driven Design. I have noticed that there is a lot of technical wording, some of which is surprisingly close to a conceptual world that even a non- techies can understand quite well. But I think that's also intentional. You can say a bit about that and maybe explain some of these terms. Michael, can you say a bit more about this?
Michael Bub: Yes, if you take a closer look at domain-driven design, there are many, many terms that come up. I just want to limit myself to a few essential ones, which I think are the crux of the whole thing. On the one hand, there is a term called aggregate. This is, so to speak, I always say casually, the star of this domain. In chess, for example, that would be the chessboard, which is the main thing I operate with. I think it is now defined concretely as a group of connected objects. So I imagine that when I design the chessboard, it also somehow has these pieces that it carries within it. It's not just a lonely chessboard, but a more complex structure that also contains these pieces and their positions, etc. In this example, that would probably be a typical chessboard. In this example, that would probably be a typical aggregate. The aggregate is characterised by the fact that it is the only component or the only class, that can receive anything this operation. It is then regulated in such a way that even if I have these figures as individual objects, I cannot address a figure directly if I model it in this way. If they are in the aggregate like that, then I always have to do it via the chessboard. This is not possible directly, so we have to talk about the topic of interface and encapsulation, so I can't play fast and loose with this figure directly, but the chessboard always has an eye on it. The move I make, it shouldn't move to Z5, a field that doesn't exist, has to be checked by the chessboard. Because its consistency is also a task of the aggregate, to make sure that an internal state is always valid in any case. It simply must not allow anyone to do anything that leads to a state that is somehow wrong. That is roughly the role of the aggregate. That is the most important thing for me in such a design. Another term is called entity. I think it is more common in computer science, and it is also a term that always comes up in the field of databases. An entity, in our chess example, would be a piece. It is a thing that has some information that it brings with it, but it has a particular ID as well, just like the aggregate, through which it can be specifically addressed. That means I don't care which white jumper I have to pull now, but it's a specific one and that's why I have to be able to name it specifically via an ID. And that's what entities represent. The last thing, and probably the easiest to understand, I would say, is the value object. You may have heard the term used in other places. For example, in our chess example, it could be the colour. That is a simple value, so to speak. It could be a more complex value. In the literature, money is often taken as an example. There you have a simple class with two attributes, which is the amount and the currency. And there's no ID, because I don't care what exactly 3 euros are, but 3 euros are always 3 euro.
Thomas Sinnwell: That all sounds a bit dry, or at least theoretical. What does such a domain model actually achieve? Why do we go to all this trouble? Why have these constructs been introduced?
Marcel Zinnow: Well, on the one hand, the domain model is there to bring the department and the software developers together. Particularly in large software projects, the functionalities can be so complex that it can no longer be managed by one person or a few individuals. This is where this domain model is important as a common language between the experts and the software developers, in order for them to communicate with each other or communicate at all. And precisely for this reason, because the entire architecture of a software, if this software architecture goes in the wrong direction from the beginning, it can be very expensive for the company. So you always consider the business and technical requirements right from the start. And that is precisely what DDD implements within the framework of this domain model or with the help of this domain model.
Thomas Sinnwell: If I have understood correctly, a very close cooperation between developers and technical experts is necessary?
Marcel Zinnow: Exactly! That is exactly what is required in domain-driven design. The domain logic is the focus of the entire design and the entire architecture of software development. And the goal is to work out the domain model together with the domain experts and the software developers. That is the basis for everything.
Thomas Sinnwell: Yes. We talked about that in detail.
Marcel Zinnow: Exactly.
Thomas Sinnwell: And that is the focus.
Marcel Zinnow: The advantages of it are, that you can focus on business functionalities, on what the experts say. Just like the technical requirements, which then come from software developers.
Thomas Sinnwell: Or from IT operations.
Marcel Zinnow: Or from IT operations. Exactly! That is a big point. Another advantage is that you also get to know the limits of a project or the requirements. A project like this always has a certain goal, a certain focus, a core functionality and this is not so obvious to the experts in the first step. And within the framework of the domain model of the elaboration of the technical terms, one simply defines boundaries. On the basis of these boundaries, it becomes clear to experts what developers are doing. What exactly are we talking about now? We are now developing the piece of software for a certain functionality or for a certain goal, and other goals, other major goals are then excluded for the time being. And that all comes about within the framework...
Thomas Sinnwell: And that's what you mean by limits?
Marcel Zinnow: Exactly!
Thomas Sinnwell: So you don't just look at the big picture, but you look at it in an agile sense: the first direction, the first functionality block, which is ideally value-adding and further additions come at a later point in the project?
Marcel Zinnow: Correct. Another advantage for the experts is that you get a bit of a common thread for the project. That’s generally with larger projects. Smaller projects on the other hand are usually subdivided and the experts get a common thread to see where they are going: This approach within the project poses questions like: where does it lead to? What is it good for? We all work together to achieve this final goal.
Thomas Sinnwell: I think another exciting aspect for the people from the departments is to learn a little bit about what perhaps has to be implemented in the background, what they see as a simple technical requirement, and what perhaps one doesn't even think about from the technical side. And this mutual development of understanding is, I believe, a very decisive step towards a successful project. I would like to look at it again: When you set up a software development project like this and then decide to use domain-driven design, how does it actually work? We have talked a lot about concepts, about terminology, about connections. But maybe the listener doesn't have a concrete idea yet: And what does that mean now? What does it look like in real life? Could you please say a bit more about this?
Michael Bub: I can try to describe my impressions. Of course, you run into problems especially when you work with several teams. So you have to be careful what you do. I just mentioned, for example, that with the aggregate, you have to make sure that it is consistent, that it corresponds to the rules of the game, so to speak. And if you let random people get their hands on these parts, which they may not know about enough, it can backfire. So you'd be well advised, even if you're developing this software, to create a certain separation between the code and the different teams. There are also various ways to organise this. There are also various concepts that come from DDD that try to coordinate certain dependencies between teams and their development, so that one doesn't necessarily mess or is too dependent on the other. There are some of these concepts that can be applied well, for example, if you only have one team. I think in particular, the bounded context, as it is called, is a very nice way of creating a certain boundary in a domain in which I am implementing, in order to say that this is exactly the core point. So I break down something bigger into something smaller and only put one team on it. So that these experts are taking care of this and other team takes care of that. Because you can get into trouble really quickly.
Thomas Sinnwell: Now that we have reached this point, I would like to talk about core professionalism. That is also a very important concept in the context of domain-driven design.
Michael Bub: Yes, exactly! There is a bit of a distinction. There is core expertise and then there are things, I would say, that you need additionally. So the old chessboard example again: When I play chess, it is essential that I understand the rules. If I have already implemented that, then I can play chess. That's fine. But now, of course, there are things that you need in addition. I need some kind of rights management. If I want to play chess, I have to identify myself first, as if I were a chess player. Not everyone is allowed to play chess, of course. Then I also need some kind of user management. And that's another topic in itself. But that is also, one would say, a different tree and context that occurs in this overall construct of chess, but which does not concern the professionalism of the actual game of chess. When developing, one would rather limit oneself to this core technicality of chess, because as I said, that's where most of the value lies. And the other things are then rather flung in.
Thomas Sinnwell: In literature, you can find statements and also, as far as the core professionalism is concerned, you have to use the very best developers. Which always made me smile a little when I read it. I really need well-established teams, and I don't just keep throwing the developers around according to the application. If I have such a well-rehearsed team, that has obvious advantages. How do you see it? Do I see it in such a detached way or do you agree with me?
Marcel Zinnow: I see it the same way you do. A well-rehearsed team like this has many advantages, especially if the team is really involved from the beginning. A software project always begins with the collection of requirements through interviews with the experts, through the preparation of documents about requirements. And the team, those are the people who work out the whole thing, who do the work and go into detail and look at everything carefully. And if the team implements the software exactly and the understanding is already there through all the interviews and all the elaborations, then this leads to much more success than if I let a team make the requirements and the interviews, and then let a completely different team, which is not at all familiar with the topic, suddenly implement the software. This then continues throughout the entire software development process until the end, until testability, and this knowledge of what is expected must come from the entire team. And the team also includes the subject matter expert, who is then supposed to test his or her subject matter expertise. If these people, if the experts are not there from the beginning, nobody knows what needs to be tested.
Thomas Sinnwell: Good! Then I would like to briefly summarise our conversation so far. Domain-driven design is a way of modelling software with the aim of implementing technical requirements as well as possible. The software development itself is done in an agile way.. The special thing about domain-driven design is the focus on the technical logic, which we have talked about extensively, and which is addressed by many aspects of domain-driven design. For the technical side, and the technical side can be in-house, but it can just as well be on the client's side.This means that the terminology used by the developers in combination with the agile approach creates a good and as precise as possible understanding between the developers and the technical side. Good! Finally, I would like to ask you two personal questions. Or what do you mean, personally, or to know from everyone: What do you see as the biggest challenge in projects that are now being implemented on the basis of Domain-driven Design? Marcel, you like to start, don't you?
Marcel Zinnow: For me, the biggest challenge in projects with domain-driven design is clearly the communication with the experts. Simply because DDD is oriented towards the agile approach, and as soon as an agile approach is attempted to be introduced into a software or a company in a software development project, it initially reaches its limits with experts who are not used to it.
Thomas Sinnwell: That's the general effect you find with people. There are few people who are always hungry for change, for something new. And with many, such a natural reaction of resistance perhaps sets in sooner. I don't know that and that means, in the end you have to go through a change of processes.
Marcel Zinnow: Right, exactly!
Thomas Sinnwell: What about you, Michael?
Michael Bub: Challenges, I would rather say it has made my life easier somehow. So, of course, as a developer, it's a bit of a challenge at first to understand everything and also to apply it correctly and to simply get behind how it can actually work. But when I look at the end result, I have to say, compared to things I've seen before, when you just have these classes that are simply data structures and then services that operate on them, that doesn't make the whole thing easy to understand or read or anything else. So I'm also a big fan of really packing this technicality together where it belongs, namely with its data on which it operates. So the rules of the game and the things that are being played with, so to speak, are kept directly in a drawer so that I can immediately see what's going on, that's what I really like about the story. And as far as that goes, I'm actually just thrilled, I almost want to say, and I can't really say that it was a big challenge, it was more of a relief.
Thomas Sinnwell: Yes, super! Thank you very much, Michael! In the title of this episode we provocatively asked the question: Who needs something like that? I think that we have now been able to answer this question for domain-driven design. And to sum up, we can say that domain-driven design is a good approach to implementing software development projects for all companies that want to map their processes through enterprise software. Why do people want something like this? There are certainly very different motivations. One reason may be that perhaps grown heterogeneous IT structures are to be replaced or the software-based processes are no longer fast enough and need to scale better. Of course, it can also be that a company does not yet have a good IT-based representation of its processes. Whatever the reason, domain-driven design is a very good way to optimally implement business requirements. Thank you very much! It was fun as always. If you have any questions or comments, feel free to check out the show notes. I'm already looking forward to the next round in four weeks. Until then, bye!
Michael Bub: Bye!
Marcel Zinnow: Bye!
That's it from us again for today. We hope we were able to take you a little further into the world of software development and keep you entertained. As always, we have further links to the current episode in the show notes and if you're interested in more, we'd be happy if you subscribe to us. By the way, there's lots more information and of course videos on our podcast topics on our YouTube channel. Just click on it! In the next episode, on the 5th of August, we will finally have the promised podcast with Christian Walter, Managing Director of the Bechtle branch in Saarbrücken. We'll be talking to him about our common credo in the IT and security sector: Breaking the silos. If you want to know what that is, just tune in. We look forward to you!