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

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

  • Downloads:8301
  • Type:Epub+TxT+PDF+Mobi
  • Create Date:2021-03-13 03:18:38
  • Update Date:2025-09-07
  • Status:finish
  • Author:Eric Evans
  • ISBN:0321125215
  • Environment:PC/Android/iPhone/iPad/Kindle

Summary

"Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing。 "His book is very compatible with XP。 It is not about drawing pictures of a domain; it is about how you think of it, the language you use to talk about it, and how you organize your software to reflect your improving understanding of it。 Eric thinks that learning about your problem domain is as likely to happen at the end of your project as at the beginning, and so refactoring is a big part of his technique。 "The book is a fun read。 Eric has lots of interesting stories, and he has a way with words。 I see this book as essential reading for software developers--it is a future classic。" --Ralph Johnson, author of Design Patterns "If you don't think you are getting value from your investment in object-oriented programming, this book will tell you what you've forgotten to do。 "Eric Evans convincingly argues for the importance of domain modeling as the central focus of development and provides a solid framework and set of techniques for accomplishing it。 This is timeless wisdom, and will hold up long after the methodologies du jour have gone out of fashion。" --Dave Collins, author of Designing Object-Oriented User Interfaces "Eric weaves real-world experience modeling--and building--business applications into a practical, useful book。 Written from the perspective of a trusted practitioner, Eric's descriptions of ubiquitous language, the benefits of sharing models with users, object life-cycle management, logical and physical application structuring, and the process and results of deep refactoring are major contributions to our field。" --Luke Hohmann, author of Beyond Software Architecture "This book belongs on the shelf of every thoughtful software developer。" --Kent Beck "What Eric has managed to capture is a part of the design process that experienced object designers have always used, but that we have been singularly unsuccessful as a group in conveying to the rest of the industry。 We've given away bits and pieces of this knowledge。。。but we've never organized and systematized the principles of building domain logic。 This book is important。" --Kyle Brown, author of Enterprise Java(TM) Programming with IBM(R) WebSphere(R) The software development community widely acknowledges that domain modeling is central to software design。 Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users。 But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process。 Domain-Driven Design fills that need。 This is not a book about specific technologies。 It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains。 Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development。 Readers learn how to use a domain model to make a complex development effort more focused and dynamic。 A core of best practices and standard patterns provides a common language for the development team。 A shift in emphasis--refactoring not just the code but the model underlying the code--in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer。 Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations。Specific topics covered include:
Getting all team members to speak the same language Connecting model and implementation more deeply Sharpening key distinctions in a model Managing the lifecycle of a domain object Writing domain code that is safe to combine in elaborate ways Making complex code obvious and predictable Formulating a domain vision statement Distilling the core of a complex domain Digging out implicit concepts needed in the model Applying analysis patterns Relating design patterns to the model Maintaining model integrity in a large system Dealing with coexisting models on the same project Organizing systems with large-scale structures Recognizing and responding to modeling breakthroughs With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations。

Download

Reviews

Evgeni Petrov

Too many abstract concepts presented with quite simplistic examples。 I would rather have seen one end-to-end example study case。

Silviu Novitchi

Contains plenty of real world examples on how the domain model design process should be done and who is involved。 The main takeaway is that the domain is evolving (through refactoring) and deeper insights are discovered during the development lifecycle。

Mantas

Reading this book is like listening grandfather's tales about his young days。 Been there, done that。 Quite boring and not very usefull。 By reading few recent articles about software design you will get the same amount or even more knowledge in much shorter time。 Maybe book was actual in time when it was written, but in 2021 it's just waste of time。 Reading this book is like listening grandfather's tales about his young days。 Been there, done that。 Quite boring and not very usefull。 By reading few recent articles about software design you will get the same amount or even more knowledge in much shorter time。 Maybe book was actual in time when it was written, but in 2021 it's just waste of time。 。。。more

Avraam Mavridis

It was my 3rd attempt to read the book and now I realized why the previous two were unsuccessful。 The book is certainly not beginners' friendly, the language is too abstract and unless you have been exposed in a particular problem it makes it difficult to understand what the author means。 It also doesn't help that there are not many code examples。 Nevertheless, the first 300-350 are gold (bounded context, ubiquitous language, repository pattern etc。), the rest of the book is way to abstract with It was my 3rd attempt to read the book and now I realized why the previous two were unsuccessful。 The book is certainly not beginners' friendly, the language is too abstract and unless you have been exposed in a particular problem it makes it difficult to understand what the author means。 It also doesn't help that there are not many code examples。 Nevertheless, the first 300-350 are gold (bounded context, ubiquitous language, repository pattern etc。), the rest of the book is way to abstract with a lot of text。。。 a lot of text。。。a few UML diagrams and no code examples。 。。。more

Jose

Confuso e muito mal diagramado。 Acho que peguei muito pouco do que ele quis passar aqui。

Trond Hjorteland

Verbose, but beautiful read。 Essential for anyone doing DDD。

alex fletcher

Possibly the worst book I’ve ever read。 Almost 20 years old and it shows。 The man rewords the same concepts and repeats them again and again。 Goes off on wild tangents from his dubious anecdotes。 Capitalises his favourite catchphrases constantly and forces them into various sentences。 It felt like it’d never end。 I can see why there are distilled versions of a similar title

Gonzalo Cardenas

Must read book for any software engineerContains valuable information, tools, and ideas on how to approach software design。 If you're serious about micro-services this is a must read。 Must read book for any software engineerContains valuable information, tools, and ideas on how to approach software design。 If you're serious about micro-services this is a must read。 。。。more

Romany Saad

Great book about software design builds on basic concepts of software design and introduced more sophisticated concepts like aggregate roots and bounded contexts, how to employ design patterns for domain modeling。the only bad note about this book is that in some occasions the writer explains a lot about obvious concepts and cut it short where it needs extra context!I recommend this book for every programmer that has 3 or more years of experience

Björn Bengtsson

This is the book to read when it comes to domain-driven design。 This is the holy bible of DDD。 It is not a heavy read, and I recommend buying a physical copy so you can highlight passages and make personal notes, because you will need to stop and reflect on many details of this book。But not all chapters need to be scrutinized。 Maybe a third of the book can be skimmed if you are not already deep down into DDD with several years of practical experience。 That said, this book definitely works well r This is the book to read when it comes to domain-driven design。 This is the holy bible of DDD。 It is not a heavy read, and I recommend buying a physical copy so you can highlight passages and make personal notes, because you will need to stop and reflect on many details of this book。But not all chapters need to be scrutinized。 Maybe a third of the book can be skimmed if you are not already deep down into DDD with several years of practical experience。 That said, this book definitely works well regardless of level of experience - it can very well be used as both reference literature and first-time study material。 。。。more

Murat Gözel

As a developer who is a learning different types of software designs, this book, shaped the most about domain-driven design in my mind。 I feel now like I have a broader vision about the structure of the software projects。

Raydhitya Yoseph

A book with a lot knowledge which needs sweat and tears to be extracted and understood。 If you make the effort, the reward will be big at the end。 The book is divided into four parts。 The first part lays the foundation of model-driven design。 It explains why and how teams should adopt model-driven design。 This part argues that teams need to have the right mindset and using a common language to make model-driven design to work。 This part also discusses the relationship between design and implemen A book with a lot knowledge which needs sweat and tears to be extracted and understood。 If you make the effort, the reward will be big at the end。 The book is divided into four parts。 The first part lays the foundation of model-driven design。 It explains why and how teams should adopt model-driven design。 This part argues that teams need to have the right mindset and using a common language to make model-driven design to work。 This part also discusses the relationship between design and implementation in a model-driven design。The second part is about the patterns or the techniques for modelling the domain into the design。 This part shows how to express model in software with entities, value objects, services, aggregates, factories, and repositories。The third part discusses refactoring in relation with the domain model。 It primarily concerns with how should refactoring and designing being done to express the model better。The four part talks about modelling in a bigger scope。 It defines bounded contexts for model and how multiple contexts interact with each other。 This last part also explores how a model in a context can be refined and the strategies for managing these contexts。I like the content of the book。 The author can put abstract concepts in my head into words。 The definitions in the book can be used to discuss modelling with my colleagues。 At one part, the book is like a dictionary。Some parts of the book also make me discover something that I never thought before。 They are thought-provoking。 I reflect the arguments with my experiences。 There is a time I agree and there is a time I disagree。 Every decision being made is indeed a trade-off。 At the other parts, the book like a debating competition。Beside the intriguing concepts and arguments, I feel the way the content of the book is delivered makes it hard to understand them。 I put an enormous effort to understand the content。 There is so many superfluous words。 Some theories in the book are explained in a few pages, but not backed by examples。 I feel like I get lost wandering in a jungle。In addition, as a non-native English speaker, I am seeing quite a few words for the first time。 I understand that the uncommon words are powerful words which can be used to express the emotion behind the sentences better, but they make the wall higher for me。In summary, this book is an awesome dictionary and contains fascinating arguments, but they are delivered in an excruciating way。 If you make the effort, you will bring a lot of stuffs for a food of thought。 I would recommended this book for readers with at least minimum 4 years experience in working with code design。 The experiences will become the examples for everything said in the books。 。。。more

Toby

Classic。 Writing style has aged but concepts remain current。

Timon Ruban

Let me start with a quote from the final pages of the book: "Although purely technological tasks have generally seemed most interesting and challenging to talented software engineers, domain-driven design opens up a new area of challenge that is at least equal。 [。。。] Wrestling a complex domain into a comprehensible software design is an exciting challenge for strong technical people。" Good domain-driven design is all about creating a model and language that works for both domain experts using th Let me start with a quote from the final pages of the book: "Although purely technological tasks have generally seemed most interesting and challenging to talented software engineers, domain-driven design opens up a new area of challenge that is at least equal。 [。。。] Wrestling a complex domain into a comprehensible software design is an exciting challenge for strong technical people。" Good domain-driven design is all about creating a model and language that works for both domain experts using the product and developers writing the code。 Doing that is hard, but it is valuable。 The book was written almost twenty years ago, but its content is probably even more relevant today than it was back then。 The last two decades have seen the rise of the product manager as a key figure of a winning product company。 UI/UX Designers are leaving their niche and turning into Digital Product Designers。 Meanwhile, I have been seeing more and more startup job ads looking for "Product Engineers"。 They are the boon of every product manager: a software engineer that actually cares about the product and not just the how of building it but also the why。 As the tooling to build operational software gets better and better, I believe the line between product and engineering will continue to blur。 And the value of a good product engineer will continue to rise。If you are a budding product engineer, this book is a must-read。 It can be verbose at times (it took me half a year of on-and-off reading to finish), but it contains many valuable principles and examples to help you become better at building and designing useful products。 。。。more

Geilton Xavier

this is a book for every programmer who really wants to write code seriously, is a very theoretical book, but excellent。If you want to take a more practical approach, I recommend reading the book by Vaughn Vernon Domain-domain Design

Felipe Leite

Good book, but as you reach the second half it becomes quite impenetrable with ill defined terms that are hard to understand。

Shyam Poovaiah

By basing your focus on domain not only do you help the users of your software but also the developers who join newly in your team。 Everything else is modeled around the domain。A course on domain driven domain on Pluralsight is a good supplement to reading this book as it shows how to design your databases around Bounded Contexts。

Ivan Kovic

I still have mixed feelings about this book。 It introduced multiple interesting ideas but it's quite hard to map instructions from the book to my everyday work。 I still have mixed feelings about this book。 It introduced multiple interesting ideas but it's quite hard to map instructions from the book to my everyday work。 。。。more

Vinicius Souza

It is a good book, but it would be better if it had its content filtered, which is, basically, "Domain-driven design distilled", by Vaugh Vernon。 Also, the book is very "theoretical", with few practical examples in code。 There is a ton of information which you (IMHO) could simply skip, which makes the book boring in some parts。 From the positive points, I cite the number of examples faced by Evans in the industry which provides good understanding of the applicability of the discipline (DDD)。 For It is a good book, but it would be better if it had its content filtered, which is, basically, "Domain-driven design distilled", by Vaugh Vernon。 Also, the book is very "theoretical", with few practical examples in code。 There is a ton of information which you (IMHO) could simply skip, which makes the book boring in some parts。 From the positive points, I cite the number of examples faced by Evans in the industry which provides good understanding of the applicability of the discipline (DDD)。 For anyone considering reading this book, I'd recommend the Vaugh Vernon pair: "Domain-driven design distilled" and "Implementing Domain-driven design"。 They are more concise and provide more practical examples。 。。。more

Tom Liversidge

It's a classic, so key concepts in here It's a classic, so key concepts in here 。。。more

Manfred Bergmann

Even though the approaches and techniques introduced in this book to a proper domain model with all the discussed variants is super,it's not an easy read。 You have to stay focused and try to capture what the author is writing, which is of massive detail。Highly recommended。 One of the best books I've read so far for software design。 Even though the approaches and techniques introduced in this book to a proper domain model with all the discussed variants is super,it's not an easy read。 You have to stay focused and try to capture what the author is writing, which is of massive detail。Highly recommended。 One of the best books I've read so far for software design。 。。。more

Du Nguyen

Uhh, so I'm pretty sure I didn't understand all the concepts but I'll try to review it anyway。 I've wanted to read this as it's one of those few timeless books in CS that occasionally gets mentioned。 Domain-Driven Design is sold as a way to produce software that is easy to understand, use, maintain and extend。 In essence what you would like your code to look like。 Evans has gathered the different principles into a pattern catalog and describes how and when to use the different patterns。The patte Uhh, so I'm pretty sure I didn't understand all the concepts but I'll try to review it anyway。 I've wanted to read this as it's one of those few timeless books in CS that occasionally gets mentioned。 Domain-Driven Design is sold as a way to produce software that is easy to understand, use, maintain and extend。 In essence what you would like your code to look like。 Evans has gathered the different principles into a pattern catalog and describes how and when to use the different patterns。The patterns are massively useful and I can see some that I have used, others I understand and see a use for and yet some others that I'm not sure I'll ever use but it's nice to know about it regardless。So far so good, my criticism of this book would be that it's too theoretical and abstract and at the same time really specific。 Most of the book is abstract in the sense that I'm sometimes not sure whether it's still about code or just general work of some sort。 I think Evans tries to decouple the technical details from the Domain-Driven design but it makes it harder for me to fully comprehend and read the book。 Most of the examples seem like they're under heavy NDA from the companies where Evans has helped as they are sometimes vague which made me struggle to understand。 For a book that emphasizes domain knowledge, the examples didn't quite explain the domain knowledge well enough for me。Sometimes Evans has code snippets which is easier for me to read and understand and the code snippets are fine in that they don't use some fancy paradigm but the object-oriented paradigm。 These snippets help a lot in comprehension。 What doesn't help comprehension is the weird mentions of beans in Java which is just a bit weird as it's such a detailed language specific thing to mention。 Overall it's worth reading and I feel there's plenty to take away from。 It's one of those books where new insights come every time it is read and I'm sure on my next read in a couple of years, more of the concepts will start making sense。 。。。more

سامح دعبس

معلومات الكتاب--------الكتاب يعرف أيضا بالكتاب الأزرق (The blue book)اسم المؤلف: إريك إيفانز Eric Evansدار النشر: Addison-Wesley Professionalسنة النشر: 2003عدد الصفحات: 563التقييم: 4 من 5المستوى: متقدم。موضوعات الكتاب----------هذا هو الكتاب المؤسس للـ Domain-Driven Design وأول كتاب أُلف في الموضوع، وأفكار الكتاب هي امتداد لأفكار أخرى مثل الـ Object-Oriented Design و الExtreme Programming وال Design By Contract وال Analysis Patterns وغيرها。الهدف من الDomain-Driven Design هو السيطرة على هذه التعقيد معلومات الكتاب--------الكتاب يعرف أيضا بالكتاب الأزرق (The blue book)اسم المؤلف: إريك إيفانز Eric Evansدار النشر: Addison-Wesley Professionalسنة النشر: 2003عدد الصفحات: 563التقييم: 4 من 5المستوى: متقدم。موضوعات الكتاب----------هذا هو الكتاب المؤسس للـ Domain-Driven Design وأول كتاب أُلف في الموضوع، وأفكار الكتاب هي امتداد لأفكار أخرى مثل الـ Object-Oriented Design و الExtreme Programming وال Design By Contract وال Analysis Patterns وغيرها。الهدف من الDomain-Driven Design هو السيطرة على هذه التعقيدات والصعوبات المصاحبة لعملية صناعة البرمجيات。 كيف ذاك؟ بالتركيز على مجال العمل (Business Domain) وعزله عن المجالات المصاحبة أو المساعدة، وكذلك عزله عن اللوازم التقنية الضرورية للنمذجة، أي تحويل مجال العمل إلى برنامج。 وهذه النمذجة هذه هي الفكرة الأولى في الDomain-Driven Design، ويمكن تسميتها الDomain Modeling، وامتداد هذه الفكرة هو استخدام نموذج واحد في التحليل والتصميم وتطبيق هذا النموذج في التنفيذ (الكود)، وهذه الفكرة تسمى Model-Driven Design。ولإيجاد هذه النموذج الموحد، وجدت الحاجة لإيجاد لغة موحدة في التواصل بين المطورين والمحللين والمتخصصين في المجال (Domain Experts) وكل ذوي العلاقة بالمشروع، وهذه اللغة تستخدم كذلك في جميع الوثائق المتعلقة بالمشروع وفي الكود والشاشات وفي كل مكان ذي صلة بالمشروع، وهذه يمكن تسميتها Ubiquitous Language (وتنطق هكذا يوبيك-وي-طاص)。 وهذه في الفكرة الثانية في الـ Domain-Driven Design。الفكرة الثالثة هي التدرج والتواصل المستمر بين كل ذوي العلاقة بالمشروع لفهم مجال العمل وتحسين نموذج البرنامج وعمليات التصميم والتطوير。 هذه هي الأفكار الرئيسية في الجزء الأول من الكتاب، ومنها انبثقت بقية أفكاره。في الجزء الثاني من الكتاب توسع المؤلف في الModel-Driven Design، فتحدث عن فكرة فصل أو عزل نموذج مجال العمال (Business Domain) ثم استعرض أنماط التصميم (Design Patterns) ذات الصلة مثل الEntities و الValue Objects وال Aggregates و ال Repositories وغيرها، وهذه الأنماط مشهورة وشائعة في أدبيات الDomain-Driven Design، حتى يظن كثير من الناس أن أنماط التصميم هذه هي ال Domain-Driven Design، وهذا من الأغلاط الشائعة، في حين أن كل الحديث عنها لم يتجاوز ثلاثة فصول من الكتاب من أصل 17 فصلا! من الأغلاط الشائعة أيضا الاعتقاد أن الDomain-Driven Design لا تطبق إلا عن طريق ال Object Oriented Programming/Design - كما قد توحي أنماط التصميم هذه، وهذا خطأ أيضا، فأي طريقة تؤدي إلى إيجاد نموذج موحد يمكن تطبيقه برمجيا جاز استعماله، ومن هذه النماذج: الWorkflow أو الـ Rule Engines، ومؤخرا صار التنفيذ باستخدام الfunctional paradigms شائعا أيضا。الجزء الثالث من الكتاب هو الذي استمتعت به أكثر شيء، ويتكلم عن ضرورة فهم مجال العمل ووسائل تحقيق هذا الفهم، وأهمها التدرج والتحسين أو إعادة البناء المستمر (continuous refactoring)، ولا يُكتفي بذلك في الكود فقط، بل في نموذج مجال العمل أيضا (model refactoring)، إضافة إلى مبادئ نافعة في تصميم البرمجيات。وفي الجزء الرابع والأخير، يتكلم الكتاب عن مبادئ التعامل مع مجالات العمل الضخمة، بالغة التعقيد، والتي تتطلب تكامل بين أنظمة وفرق مختلفة。 ولا يُذكر التكامل إلا و يذكر معه تقاطع التقنية مع السياسة! ومن الأفكار التي وردت في هذا القسم: تقسيم مجال العمل إلى مجالات أساسية (Core Subdomain) ومجالات فرعية، وتطبيق ذلك على الBounded Contexts أو مجال تطبيق اللغة المشتركة المذكورة آنفا، وال Context Maps أي العلاقة بين الBounded Contexts المختلفة، وما يتفرع عن هذه الأفكار - وهو كثير، حيث يستغرق هذا الجزء وحده أكثر من ثلث الكتاب! -، وكذلك الكلام على التدرج في المعمارية (Evolutionary Architecture) - وإن لم ترد بهذا الاسم في الكتاب - 。tملاحظات عامة على الكتاب------------المؤلف يحكي الكثير من التجارب الشخصية الناجحة والفاشلة وهذا يعطي مصداقية لكلامه。الكتاب يبدأ بالتفاصيل ثم يتدرج للصورة الكلية (bottom-up) لكن أهمية الأفكار في الكتاب - من وجهة نظري -هي بعكس هذا الترتيب。الكتاب دسم جدا ومليء بالأفكار الملهمة، ولذلك لا يصلح للمبتدئين، وعلى الرغم من ذكره بعض الأمثلة التطبيقية لكنها لا تكفي لتمكينك من تطبيق كل هذه الافكار بنفسك。。اقتباسات من الكتاب----------Manufacturing is a popular metaphor for software development。 One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products。 This metaphor has messed up a lot of projects for one simple reason—software development is all design。 All teams have specialized roles for members, but over-separation of responsibility for analysis, modeling, design, and programming interferes with MODEL-DRIVEN DESIGN。 。。。more

Giovanni Crescencio

Te enseña un enfoque nuevo de cómo atacar el problema que se va a programar, tiene buenos ejemplos de cómo modelar y mantener el modelo, tiene un punto de vista filosófico del problema, los ejemplos que muestra no son aburridos y enfocados, esta lleno de buenas prácticas, todo programador debería leerlo

Alexey

The book provides a good entry point into analysis and design of large software systems and introduces a group of architectural patterns。

Βασίλης Τσακίρης

The book is gold。I am lucky to have read it at the beginning of my software engineering career。

Ioram Gordadze

The author is really experienced and has deep insights in discussed concepts。Imho this book has two major downsides:1。 It's unnecessarily long and repetitive in many places。2。 It's not beginner friendly at all。 This is a dry theory written through a long list of pages, and if the reader hasn't experienced discussed concepts in practice it will be hard for him/her to grasp ideas behind them。 The author is really experienced and has deep insights in discussed concepts。Imho this book has two major downsides:1。 It's unnecessarily long and repetitive in many places。2。 It's not beginner friendly at all。 This is a dry theory written through a long list of pages, and if the reader hasn't experienced discussed concepts in practice it will be hard for him/her to grasp ideas behind them。 。。。more

Sandy Maguire

For some reason this book is greatly beloved in programming circles。 I can't tell if that's because the people doing the beloving are die-hard Java Enterprise programmers, or if I'm just missing something here。 But I think it's the former。Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used。" What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussio For some reason this book is greatly beloved in programming circles。 I can't tell if that's because the people doing the beloving are die-hard Java Enterprise programmers, or if I'm just missing something here。 But I think it's the former。Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used。" What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussions about shipping containers。 And that's saying something, coming from a guy who reads excessively dry boring math and engineering books on the regular。If I had to be charitable, I would say that this book is independently groping towards functional programming without knowing it, and trying to shoehorn the ideas into an OOP-mindset。 There is a lot of potential here for things to like, but it ultimately falls short。 If you've only ever coded in Java, or frequently sketch UML diagrams, this might be the book for you。 And if so, may god have mercy on your soul。 。。。more

Melika Barzegaran

I'd heard about domain-driven design and had read about that here and there, and I wanted to know more。 So, I picked up this book。Disappointingly, reading it was a very painful experience。 Ideas were scattered and lacked focus。 Examples were unnecessarily complicated and lacked enough context to be educational。 Sentences were repeated and repeated again without adding much value。 The whole idea of the book could be simply presented in a blog post。If you're like me and want to know more about dom I'd heard about domain-driven design and had read about that here and there, and I wanted to know more。 So, I picked up this book。Disappointingly, reading it was a very painful experience。 Ideas were scattered and lacked focus。 Examples were unnecessarily complicated and lacked enough context to be educational。 Sentences were repeated and repeated again without adding much value。 The whole idea of the book could be simply presented in a blog post。If you're like me and want to know more about domain-driven design, just read some blog posts on the topic, or watch some recordings of conferences regarding the concept。 It saves your time and you can learn much more。 。。。more

Aaron Munger

Did not make it through, the organization of this book did not flow well for me and I just couldn't pay attention long enough to really get any meaning out of most chapters。 Maybe I'll try again if I move into an applied science field, but this book is not targeted towards writing dev tools。 Did not make it through, the organization of this book did not flow well for me and I just couldn't pay attention long enough to really get any meaning out of most chapters。 Maybe I'll try again if I move into an applied science field, but this book is not targeted towards writing dev tools。 。。。more