Vaughn Vernon

Some background: I am a intermediate/senior-cusp SRE. I have spent the last year working to take our single-tenant AWS EC2 monolithic deployments and getting it working via container-based deploys, with the future looking towards multi-tenancy and carving up new and old features into microservices. As our company has grown I have had to think about our future scalability from ideation to maintenance, as well as deal with the ramifications of our previous non-scalable iterations.

This book made my head hurt, and it is what I imagine to be an _introduction_ to the subject! I shudder to think about what the original work is like!

I will grant that this book is a very succinct explanation of the topic. Too succinct; it appears as though DDD has a lot of ground to cover, and this book chooses to not really delve into the why of it, assuming that this is an orientation book for someone who has been won over by the original material or is a primer for someone who doesn't get any say in the matter (or to orient themselves around the persuasive package the provider will also supply.)

If I had read this book a few years ago, I probably would not have valued it. But as I was reading this book, in the back of mind, I see how years of research and struggle on my part could have lead to these concepts, or something like them. In many ways this makes it a bad introduction outside the above tow cases ... if I am picking this up out of curiosity or expecting to be won over, this book will not satisfy. And it doesn't pretend to, but it also doesn't advertise this fact and it's very easy to assume from its descriptions and packaging that it is a typical introduction to a methodology, which will include a persuasive introduction. This book takes that on faith.

I'm not sold on DDD as _the_ software methodology. But what I do appreciate is that it is a very thorough _vocabulary_ and worflow for a particular implementation of a bunch of practices and strategies that ostensibly lead to large, scalable software. This book is a behemoth to read, but it is a clear source of definitions and processes, and without entirely understanding the why (which I'm sure the author's workshop would provide :)) I could apply the lingo and apply some of the practices well enough, although possibly without the larger picture. And for what the author seems to have optimized this book for, perhaps it is enough.

One thing this book cleared was my unfair distrust of DDD as the reason why so many objected-oriented programs use horrible class structures in their code that shoehorn business objects into code in a way that does not match with object-oriented mechanics in any way beneficial or harmless to the developer; it is very clear fro mthis book that the concepts of bounded context (a business area of concern that some portion of code is responsible for) and its ubiquitous language (the words that make up the business operations and entities in that bounded context) are things to be defined at a level higher than code organization, although it will very much influence it.
It also cleared up to me that it is _possible_ to use this metholodgy with non-purely-objected-oriented environments, although the book chooses to omit the conceptual mapping in favour of its brevity and the fact that Object-Oriented Programming is so common.

I don't think this book is where one should stop ... it is very likely that books and courses by the author are necessary in order to understand the larger aspects of scalable software development that DDD is attempting to solve, and for decision makers that is a shame, because the level of complexity makes it a hard sell that will not be appreciated until a developer realizes they have been struggling with all of these problems and that DDD could be a well-described framework for a _possible_ solution.

In so many ways this is not a book for developers in their implementation prime ... this book is all about the kinds of things that will slow them down and ruin their beautiful software models. But this is the kind of book that promises a way for people who have to deal with large services, services in the cloud, services that can no longer be a single artifact. I wish I could recommend a set of books to understand the need before this one ... the more detailed DDD books seem like a circular suggestion, but perhaps [b:Release It!: Design and Deploy Production-Ready Software|1069827|Release It! Design and Deploy Production-Ready Software (Pragmatic Programmers)|Michael T. Nygard|https://i.gr-assets.com/images/S/compressed.photo.goodreads.com/books/1328765022l/1069827._SX50_.jpg|1056502] and [b:Designing Data-Intensive Applications|23463279|Designing Data-Intensive Applications|Martin Kleppmann|https://i.gr-assets.com/images/S/compressed.photo.goodreads.com/books/1415816873l/23463279._SX50_.jpg|43055831] would suffice, especially when being read to solve very present problems on one's project.


… (más)