What is DDD?
- [Instructor] So let's dive into the details. Domain-driven design was developed by Eric Evans back when dinosaurs roamed the earth, which means that things like microservices and agile didn't really exist at the time. Microservices brought domain-driven design back to the fore because as it turns out, it's an almost ideal way to design a set of microservices. That said, the original work was done in a non-microservice monolithic world, which is to say that the techniques that we're going to look at work just as well in the monolith as they do with the set of microservices. I will however talk about microservices later on in the course. Eric's book is a good book but it turns out there's been some work done since then. So if you're going to supplement this class in order to dive into the details, and you will have to do that because the class doesn't cover all the details, I strongly recommend Vaughn Vernon's book called Domain-Driven Design Distilled. It covers all of the critical stuff that Eric's book covers but it's a little bit more up-to-date and it's a little bit more concise. And both of those are good things. Now, what is domain-driven design? It has several characteristics, the first of which is that it is a collaborative process. Now, the quote here, "Business people and developers "working together," comes from the agile manifesto, of course. So one of the other characteristics of domain-driven design is that it is very, very appropriate for an agile workflow because the underlying philosophy of DDD and the underlying philosophies of agile are almost identical. So step one is that it's collaborative. Step two, characteristic two, is that domain-driven design is built on the notion of modeling. The basic idea is that the structure of your code should model or map to the structure of the domain within which the problem is being solved. So your domain might be accounting, it might be a storefront, it might be anything that makes sense to business users. And the idea is that a business user should be able to look at the overall large structure of your system and make sense of it. That means that when changes happen in one place it's easy to make changes in the other. And that's one of the main advantages of a DDD approach. In other words, changes happen in the domain. They don't happen in the code, they happen in the domain. So when that happens, you need to be able to get the equivalent change in the code as easily and as quickly as possible. If there is a one-to-one mapping between the code and a domain, when a change happens in the domain you know exactly where to look in the code in order to make that change. The third characteristic of DDD that's important is that it's incremental. Now, the basic idea of an incremental approach is that you don't come up with a big architecture up front before you do any coding. Instead, you come up with just enough architecture to solve the problem that's right in front of you. Then as you implement that, you learn more about the problem. And that means that you have to go and change the architecture in order to accommodate whatever new things you learn as the code evolves. That's the agile way of working, of course. DDD was designed with that in mind. The basic idea then is that a domain-driven design architecture will allow your code to grow incrementally over time because the architecture itself grows incrementally over time. Now, what makes that work is the fact that the domain itself provides an architectural coherence that you wouldn't have if you were just looking at things like the hardware. So the DDD approach then lends itself to incremental development. Now, of course the domain is going to influence the system. And we're all very much aware of that. It is the things that happen, things that, changes that are made in the domain influence the underlying software. What we don't think about though, which is equally important, is that this is really not a linear process. As the domain influences the system but the system also influences the domain. In other words, DDD is designed for a world in which you are releasing incrementally. So what that means is that every time you release into the actual domain, users will use the code that you just released and that will change the domain to some extent. So there's actually a cycle here is that you create a little bit of code, you release the code to your users, your users start using that code, and that changes the way they work, which is going to cause other changes to happen within the system itself. It's a cyclic process. So DDD is again very appropriate for that sort of cyclic working because again, what you're modeling is the actual domain that's actually in front of you. And changes are easy to make because there's that one-to-one between the domain and the underlying system.
No comments:
Post a Comment