Domain-Driven Design: Tackling Complexity in the Heart of Software

I figured this would be a good addition for someone without a lot of formal education in software development. This is a great read that will validate a lot of your latent knowledge in software design, including layered architecture, common patterns, and all the things to watch out for when designing robust software.

The book explains concepts and patterns very well. Each definition comes along with a good example to make the whole idea clearer. Each pattern can solve only a class of problems and Eric Evans highlights when and why to apply a specific pattern, also provides scenarios to combing patterns for a more expressive system.Principles that must be present in a software project are highlighted (such as communication through a language used by all team members, a language that is built from discussions with domain experts). Importance of software design and how it favors problem solving and clear communication between team members and teams.For a while I was looking at refactoring as a "thing to do when the software is done if time allows it", Eric Evans highlights refactoring as a necessity and must not be neglected because continuous refactoring leads to deeper knowledge and understanding of what the Software needs to do and how it actually does it.Practical problems such as the possibility of multiple models to exist within the same system have been addressed and given solutions from using one common (unified) model in the whole system (also the costs of such a choice are presented) to totally independent models. An algorithm described in steps is presented for getting two totally independent models to be completely unified allows designers and developers to combine any part of their software towards new features required by the business.Also a common problem at this time is integration with legacy systems (there are lots of systems that were written using old, now unreliable, components that need migration towards newer, safer, faster components), this problem is approached and it's solution is detailed from beginning to end where the system is completely migrated.Last but not least, a small oriented graph is given to visualize how concepts in the book are connected and how all pieces fall into the puzzle. Any software developer should read this book at least one time.

In italian we have this fun saying" "Dalle stelle alle stalle" which can be translated to "From the stars to the stables" meaning going from brilliant and promising beginnings to a low and humbling ending.. well I find that it describes perfectly this book. Writing a bad tech book is already a mortal sin without making things even worse by raising reader's expectations with a pompous title like "tackling complexity in the heart of sofware". The only thing that this book tackles is the patience of the reader forced to wade through a sea of fluff to find the few interesting ideas that are actually present. It's not that this book contains zero value, it does present some interesting ideas, but the level, usefulness and impact of these ideas are barely enough to justify a series of blog posts, not a book and certainly not a 500 pages book! Add to this lack of structure and organization, continuous repetitions and a pompousness beyond imagination with the annoying habit of continually uppercasing or bolding the "important ideas" and inventing pompous sounding name for simple concepts in the vain attempt to hide their triviality and you will have an idea of the torments that await you if you buy this book and attempt to read it.The truly facinating question is: "how did this barely decent series of blog posts manage to get so popular and receive respect and good reviews?". I think the answer lies on its cover. It's like with modern art and abstract painting... some guy puts together something kind of original or vaguely interesting or just plain strange, a couple of critics start praising its outstanding aestetics and deep meaning for personal reasons of just as a way to praise themselves who are the only ones able to discern such beauty and meaning , they present the work in an elegant and "important" location and well.. the rest of us deep inside still think it 's fried air, but we still go to the exhibit and dare not say so, since well.. if it's so higly regarded there must be a reason, and maybe it's just that I am not good enough to get it... That's why the best qualification for this book and the attitude it promotes "kandinskian". A (hopefully) failed attempt to transfer to software design and development the horrors of art criticism.And to the author and whoever shares his love for pompous sounding words and names (or as he would say it: "UBIQUITOUS LANGUAGE") I would advise to reflect on this Feynman quote:"You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's doing -- that's what counts. I learned very early the difference between knowing the name of something and knowing something."

This work was published in 2004 – a lifetime ago for the field of software design. It tackles issues relevant in 2004 but are standard practice today. Its basic message – learn not just the software but also the domain – is an important one, but most of the insights has been absorbed into computer-programming praxis over the last fifteen years.Its strength is in delineating how the programmer is to relate to the domain experts who teach the programmer about the application area. He defines the term “ubiquitous language” to describe the language and concepts the two must share. I like this concept, but I think that the chosen wording should be “common language” instead of referring to the concept of ubiquity (whose meaning is closer to everywhere than shared or common).This book had its time and place. However, for the $50+ price current on the market, I suggest that its time and place has passed. It has contributed to history, and one should appreciate those effects. Nonetheless, contemporary design concepts – like Agile development or the DevOps movement – certainly deserve more attention from the reader.

This is serious book about domain modeling in software design. Software development society lives from one hype wave to another. OOP, patterns, XP, TDD, CI/CD, BigData, DevOps - this is just to name few. This book is originated from golden age of OOP. The author admits that object oriented paradigm is not the only one available but the bias toward OOP/OOD is obvious (and justifiable). This book tells about how to do the modeling of core software components “the right way”.With fast pace of modern software development, it’s easy to forget that the main part of software value is in its “brains”. You can change GUI technology or infrastructure layer. You even can totally rewrite your application but the application domain stays more or less the same and at the end of the day the model defines whether this software is useful or not.I can say that this book is targeting architects, domain experts, business analysts (and I believe these professionals are the main audience) but this would be the usual fallacy of separating software developers into first and second class. So I say the opposite – if you want to transcend from craft of software development to its art you should read this book.

After reading this book, I felt head and shoulders above my peers in how to create APIs. It gives great examples to help both developers and business domain owners theor roles in applying technical solutions to business problems.

This is a very important book for the developer community.Not just about code. Lots of content on how to organize teams around business value, and how that is reflected in the design of your system.The only thing keeping me from a 5th star is that it can be a very dry book in certain areas. There also could have been more code samples and less UML and walls of pure text.Bounded contexts are the most important concept to take away from this book.If you're on the fence, go and check out Eric Evans' talks on YouTube.

Do not be afraid by the publish date of this book (2003). Its concepts are timeless!Every mid- to senior-level developer who is serious about their craft must read this book. I am confident that well written (i.e. SOLID), maintainable software is impossible to achieve without a model-driven design perspective. Simply using "design patterns" is not enough. This book gives you the knowledge behind model-driven design (or Domain-Driven design) and how to apply it (albeit in abstract ways--as every software project and its requirements are different--better stated, you just need to practice the concepts within and gain experience with them in order to more effectively use them over time).I read a copy of this years ago, but at my level of software development maturity, I was not ready for the concepts presented and found it difficult to read. Having a few more years under my belt, I decided to purchase my own copy (Hardback, no less!!) and immediately began to read it again. I am truly excited about what I'm (re)learning in this book and can't wait to begin trying to view software systems and business requirements through the lens of model-driven design.