[Implementing Domain-Driven Design.torrent
Ted Brathwaite
Domain-Driven Design (DDD) is a software design approach that focuses on modelling software to match a domain according to input from that domain's experts. It emerged in late 90s and started to gain traction in the first decade of the 21st century. Lately many software development companies strive to implement it in their processes. But how should you as a developer get acquainted with it?
Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software" 2003 book is considered to be the book about DDD (also known as the blue book). However it is quite repulsive with its big price and reputation for being cumbersome to read. So how could you as a developer get a grasp of what DDD is without investing a lot of time?
You may be tempted to read the green book "Domain-Driven Design Distilled" by Vaughn Vernon. It is advertised as an accessible guide to the main principles of DDD. I fell for the trap, read it and found a lot of thing wrong with it. And I am really keen to tell about it and suggest a better alternative.
You would think that a small "distilled" version of a book about DDD should focus on creating a picture of what Domain-Driven Design is. But in fact I found myself puzzled about what it actually is after finishing this book.
The picture I got was a middle managers look on DDD: it's another practice that involves moving stickers on the wall until developers get at least some understanding of what the business wants. The book went into very little detail explaining the building blocks of a software system designed in domain-driven manner. And what it seems like no detail on how actual domain concepts should map into the software.
Instead I found myself reading multiple paragraphs on what colours and sizes your stickers should be which is bizarre to me. And there were only what felt like a few words on what aggregates and its elements are. Do not get me wrong: explaining how to employ event stormings to start using DDD is important but it should not focus on sticker colours this heavily.
Another thing in the book I found counterintuitive and unhelpful is the path it takes to explain DDD. It starts from scalability with multiple subdomains which you might not even have in your domain. And for the first 50 or so pages you see words like aggregates, events, entities that you can only guess the meaning of. I believe that those concepts are crucial in the understanding of scalability mechanisms in DDD and should always come before those.
Still the book is not useless. Perhaps if you already have some understanding of many DDD concepts and only need to bind them together this book will be largely helpful. And obviously it is good at what it really is: selling Domain-Driven Design to managers. But for practicing developers with a goal to understand how to use and implement Domain-Driven Design it is certainly a bad choice.
There is actually a somewhat hidden gem in the world of books about DDD. "Domain-Driven Design Quickly" by Abel Avram and Floyd Marinescu is a free (if we are talking about the PDF/epub version) book that brilliantly summarises Eric Evans' blue book.
It follows a predictable path of explaining DDD with concrete examples which builds a real picture of a project build with DDD. It also gives the understanding of hexagonal architecture that usually comes with DDD.
To me this book felt like the actual "distilled" version of DDD. Still it only paints a picture with the theory on DDD. I felt like I still required more practical examples to really finish digesting all the information I recieved. And there is no better way to do this than to look at a real project template built with DDD and to read a few articles with different opinions and points of view on implementing DDD.
For this there is an absolutely brilliant repository by Sairyss on GitHub. domain-driven-hexagon properly implements hexagonal architecture with some of more advanced practices in TypeScript and Nest.js. Most aspects of DDD are explained in a simple language with an example in the code and links to relevant articles. Despite the fact that it is written in TypeScript you will still largely benefit from the information displayed in the repository and most likely interpret code examples well enough even if you are not familiar with JavaScript.
So if you as a developer find yourself interested in Domain-Driven Design but not invested enough to read Eric Evans' blue book you should start with "Domain-Driven Design Quickly" by Abel Avram and Floyd Marinescu and then see some practical examples in domain-driven-hexagon to really build an understanding of DDD. I hope this article saved you from investing your precious time into an unworthy book and paved a better path of getting to know DDD.
The idea of using DDD is really for large, complex software. Otherwise it could happen that you invest your time in a wrong way. After all if you just use the layered architecture correctly, you isolate the domain (what hexagonal architecture does), and you can still model your domain well even without DDD patterns.
The question here is, why do you need DDD? The idea of Vernon with the distilled book, was to create an easy and fast understanding for the IT-community. In order that managers understand the values of DDD, and inspire the developers to use it.
The point that Vernon tries to share is, you first have to adapt the environment for scaling the application (which are the strategic designs), before you start coding (or use the tactical design). So it is definitely not a coding book. You probably were just looking for something else.
I read DDD Distilled. Somehow for years I skipped learning about DDD.
I thought it was terrific. The hardest part by far is not being able to apply much of it because it requires a degree of organizational buy-in.
Although my friend claims Vaughn Vernon's DDD Distilled is a must-read book! This is an exciting guide to domain-driven design that will open up new horizons for developers. I researched top writers a lot, found edubirdie.com/top-writers for this. I can not add this author there yet. Author Vaughn Vernon presents complex concepts in a simple and understandable way. This makes the book a valuable resource for anyone interested in programming and software design.
This is the second part of our in-depth series on Domain-Driven Design (DDD). Part one discussed strategic domain-driven design, whereas, in part three, you'll learn how to apply domain-driven design to working software using Java and Vaadin. Updated for 2023.
In this article, we are going to learn about tactical domain-driven design. Tactical DDD is a set of design patterns and building blocks that you can use to design domain-driven systems. Even for projects that are not domain-driven, you can benefit from using some of the tactical DDD patterns.
Tactical design is much more hands-on and closer to the actual code than strategic domain-driven design. Strategic design deals with abstract wholes, whereas tactical design deals with classes and modules. Tactical design aims to refine the domain model to a stage where it can be converted into working code.
Design is an iterative process, so combining strategic and tactical design makes sense. You start with strategic design, followed by tactical design. The biggest domain model design revelations and breakthroughs will likely happen during tactical design, and this, in turn, can affect the strategic design, so you repeat the process.
Again, the content is very much based on the books Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans and Implementing Domain-Driven Design by Vaughn Vernon. I highly recommend you read both of them. Like in the previous article, I have chosen to explain as much as possible in my own words, injecting my own ideas, thoughts, and experiences where appropriate.
One of the most important concepts in tactical DDD is the value object. This is also the DDD building block I use the most in non-DDD projects, and I hope you will too after reading this.
A value object is an object whose value is of importance. This means that two value objects with the exact same value can be considered the same value object and are thus interchangeable. For this reason, value objects should always be made immutable. Instead of changing the state of the value object, you replace it with a new instance. For complex value objects, consider using the builder or essence pattern.
Value objects are not only containers of data - they can also contain business logic. The fact that the value objects are also immutable makes the business operations both thread-safe and side-effect free. This is one of the reasons I like value objects so much and why you should try to model as many of your domain concepts as possible as value objects. Also, try to make the value objects as small and coherent as possible, making them easier to maintain and reuse.
Instead of using a BigDecimal for monetary values, use a Money value object that wraps a BigDecimal. If you are dealing with more than one currency, you may want to create a Currency value object as well and make your Money object wrap a BigDecimal-Currency pair.
Using value objects like this has several advantages. First of all, they bring context to the value. You do not need to know whether a specific string contains a phone number, an e-mail address, a first name, or a postal code, nor do you need to know whether a BigDecimal is a monetary value, a percentage, or something completely different. The type itself will immediately tell you what you are dealing with.
Secondly, you can add all the business operations that can be performed on values of a particular type to the value object itself. For example, a Money object can contain operations for adding and subtracting sums of money or calculating percentages while ensuring that the precision of the underlying BigDecimal is always correct, and that all Money objects involved in the operation have the same currency.
795a8134c1