序
前言
致谢
关于作者
如何使用本书、
Chapter 1 Getting Started with DDD
Can I DDD?
Why You Should Do DDD
How to Do DDD
The Business Value of Using DDD
1. The Organization Gains a Useful Model of Its Domain
2. A Refined, Precise Definition and Understanding of the Business Is Developed
3. Domain Experts Contribute to Software Design
4. A Better User Experience Is Gained
5. Clean Boundaries Are Placed around Pure Models
6. Enterprise Architecture Is Better Organized
7. Agile, Iterative, Continuous Modeling Is Used
8. New Tools, Both Strategic and Tactical, Are Employed
The Challenges of Applying DDD
Fiction, with Bucketfuls of Reality
Wrap-Up
Chapter 2 Domains, Subdomains, and Bounded Contexts
Big Picture
Subdomains and Bounded Contexts at Work
Focus on the Core Domain
Why Strategic Design Is So Incredibly Essential
Real-World Domains and Subdomains
Making Sense of Bounded Contexts
Room for More than the Model
Size of Bounded Contexts
Aligning with Technical Components
Sample Contexts
Collaboration Context.
Identity and Access Context.
Agile Project Management Context
Wrap-Up
Chapter 3 Context Maps
Why Context Maps Are So Essential
Drawing Context Maps
Projects and Organizational Relationships
Mapping the Three Contexts
Wrap-Up
Chapter 4 Architecture
Interviewing the Successful CIO
Layers
Dependency Inversion Principle
Hexagonal or Ports and Adapters
Service-Oriented
Representational State Transfer―REST
REST as an Architectural Style
Key Aspects of a RESTful HTTP Server
Key Aspects of a RESTful HTTP Client
REST and DDD
Why REST?
Command-Query Responsibility Segregation, or CQRS
Examining Areas of CQRS
Dealing with an Eventually Consistent Query Model
Event-Driven Architecture
Pipes and Filters
Long-Running Processes, aka Sagas
Event Sourcing
Data Fabric and Grid-Based Distributed Computing
Data Replication
Event-Driven Fabrics and Domain Events
Continuous Queries
Distributed Processing
Wrap-Up
Chapter 5 Entities
Why We Use Entities
Unique Identity.
User Provides Identity
Application Generates Identity
Persistence Mechanism Generates Identity
Another Bounded Context Assigns Identity
When the Timing of Identity Generation Matters
Surrogate Identity
Identity Stability.
Discovering Entities and Their Intrinsic Characteristics
Uncovering Entities and Properties
Digging for Essential Behavior
Roles and Responsibilities
Construction
Validation
Change Tracking
Wrap-Up
Chapter 6 Value Objects
Value Characteristics
Measures, Quantifies, or Describes
Immutable
Conceptual Whole
Replaceability
Value Equality.
Side-Effect-Free Behavior
Integrate with Minimalism.
Standard Types Expressed as Values
Testing Value Objects
Implementation.
Persisting Value Objects
Reject Undue Influence of Data Model Leakage.
ORM and Single Value Objects
ORM and Many Values Serialized into a Single Column
ORM and Many Values Backed by a Database Entity.
ORM and Many Values Backed by a Join Table.
ORM and Enum-as-State Objects
Wrap-Up
Chapter 7 Services
What a Domain Service Is (but First, What It Is Not)
Make Sure You Need a Service.
Modeling a Service in the Domain
Is Separated Interface a Necessity?
A Calculation Process
Transformation Services.
Using a Mini-Layer of Domain Services
Testing Services.
Wrap-Up
Chapter 8 Domain Events
The When and Why of Domain Events
Modeling Events
With Aggregate Characteristics
Identity
Publishing Events from the Domain Model
Publisher
Subscribers
Spreading the News to Remote Bounded Contexts
Messaging Infrastructure Consistency
Autonomous Services and Systems
Latency Tolerances
Event Store
Architectural Styles for Forwarding Stored Events
Publishing Notifications as RESTful Resources
Publishing Notifications through Messaging Middleware
Implementation
Publishing the NotificationLog
Publishing Message-Based Notifications
Wrap-Up
Chapter 9 Modules
Designing with Modules
Basic Module Naming Conventions
Module Naming Conventions for the Model.
Modules of the Agile Project Management Context
Modules in Other Layers
Module before Bounded Context
Wrap-Up
Chapter 10 Aggregates
Using Aggregates in the Scrum Core Domain
First Attempt: Large-Cluster Aggregate
Second Attempt: Multiple Aggregates
Rule: Model True Invariants in Consistency Boundaries
Rule: Design Small Aggregates
Don’t Trust Every Use Case
Rule: Reference Other Aggregates by Identity
Making Aggregates Work Together through Identity
References
Model Navigation
Scalability and Distribution
Rule: Use Eventual Consistency Outside the Boundary
Ask Whose Job It Is
Reasons to Break the Rules
Reason One: User Interface Convenience
Reason Two: Lack of Technical Mechanisms
Reason Three: Global Transactions
Reason Four: Query Performance
Adhering to the Rules
Gaining Insight through Discovery.
Rethinking the Design, Again
Estimating Aggregate Cost
Common Usage Scenarios
Memory Consumption
Exploring Another Alternative Design
Implementing Eventual Consistency.
Is It the Team Member’s Job?
Time for Decisions
Implementation
Create a Root Entity with Unique Identity
Favor Value Object Parts
Using Law of Demeter and Tell, Don’t Ask
Optimistic Concurrency.
Avoid Dependency Injection.
Wrap-Up
Chapter 11 Factories
Factories in the Domain Model
Factory Method on Aggregate Root
Creating CalendarEntry Instances
Creating Discussion Instances
Factory on Service
Wrap-Up
Chapter 12 Repositories
Collection-Oriented Repositories
Hibernate Implementation
Considerations for a TopLink Implementation
Persistence-Oriented Repositories
Coherence Implementation
MongoDB Implementation
Additional Behavior
Managing Transactions
A Warning
Type Hierarchies
Repository versus Data Access Object
Testing Repositories
Testing with In-Memory Implementations
Wrap-Up
Chapter 13 Integrating Bounded Contexts
Integration Basics
Distributed Systems Are Fundamentally Different
Exchanging Information across System Boundaries
Integration Using RESTful Resources
Implementing the RESTful Resource
Implementing the REST Client Using an Anticorruption Layer
Integration Using Messaging
Staying Informed about Product Owners and Team Members
Can You Handle the Responsibility?
Long-Running Processes, and Avoiding Responsibility
Process State Machines and Time-out Trackers
Designing a More Sophisticated Process
When Messaging or Your System Is Unavailable
Wrap-Up
Chapter 14 Application.
User Interface
Rendering Domain Objects
Render Data Transfer Object from Aggregate Instances
Use a Mediator to Publish Aggregate Internal State
Render Aggregate Instances from a Domain Payload Object
State Representations of Aggregate Instances
Use Case Optimal Repository Queries.
Dealing with Multiple, Disparate Clients
Rendition Adapters and Handling User Edits
Application Services
Sample Application Service
Decoupled Service Output
Composing Multiple Bounded Contexts
Infrastructure
Enterprise Component Containers
Wrap-Up
Appendix A Aggregates and Event Sourcing: A+ES
Inside an Application Service
Command Handlers
Lambda Syntax
Concurrency Control.
Structural Freedom with A+ES
Performance
Implementing an Event Store
Relational Persistence
BLOB Persistence
Focused Aggregates
Read Model Projections
Use with Aggregate Design
Events Enrichment
Supporting Tools and Patterns
Event Serializers
Event Immutability
Value Objects
Contract Generation
Unit Testing and Specifications
Event Sourcing in Functional Languages
Bibliography
Index
这本《实现领域驱动设计》英文版,从标题上就带着一种沉甸甸的期待感。读完后,我首先想到的不是具体的技术实现,而是一种思维模式的颠覆。在项目实践中,我们常常陷入技术细节的泥潭,忽略了业务本身的复杂性和核心价值。这本书就像一股清流,引导我们跳出“怎么做”的陷阱,去思考“我们到底要做什么”。它教会我如何更深入地理解业务需求,如何用一种更具表现力、更贴近业务语言的方式来构建软件。书中关于“限界上下文”的概念,对我触动尤其大。过去,我们常常在项目初期就尝试构建一个大而全的系统,结果往往是越到后期越难以维护,不同模块之间的耦合像藤蔓一样缠绕不清。而“限界上下文”提供了一种解耦的思路,让我意识到将复杂的领域划分成更小、更自治的单元是多么重要。这不仅能提高开发效率,更能保证系统的可扩展性和可维护性。虽然我还没完全消化书中的所有概念,但仅仅是这种对软件设计理念的重塑,就足以让我觉得这次阅读物超所值。它让我重新审视了过去的一些项目,理解了为什么有些项目会走向失败,也为我未来的项目设计指明了一个更清晰的方向。这本书更像是一本哲学著作,它探讨的是如何用更聪明、更有效的方式去应对软件开发的本质挑战。
评分阅读《实现领域驱动设计》这本书,就像是在一个高维度的空间里俯瞰整个软件开发过程。它让我跳出了日常编码的琐碎,站在更高的视角去审视软件的架构和设计。书中关于“战术模式”和“战略模式”的区分,给了我非常大的启发。战略模式,如限界上下文、上下文映射图,帮助我理解如何将庞大的业务领域划分成易于管理的模块,并理清它们之间的关系。而战术模式,如实体、值对象、聚合,则提供了在每个模块内部进行细粒度设计的具体方法。我特别喜欢书中关于“聚合根”的解释,它强调了数据一致性的重要性,并提供了一种管理复杂对象图的方式。在实际开发中,我们常常会遇到数据不一致的问题,导致系统出现各种意想不到的错误。而通过识别聚合根,并围绕它来设计数据访问,可以有效地避免这些问题。这本书的逻辑性非常强,每一章的内容都建立在前一章的基础上,形成了一个完整的知识体系。它不像一些技术书籍那样,只是罗列一些零散的技巧,而是提供了一个系统性的方法论,让我能够从根本上提升软件设计的水平。
评分我一直认为,好的软件设计不仅仅是代码的堆砌,更是对业务的深刻理解和巧妙的抽象。而《实现领域驱动设计》这本书,恰恰在这两方面都做得非常出色。它并没有仅仅停留在理论层面,而是用大量的实例和代码片段,演示了如何将DDD的原则转化为实际可用的解决方案。我尤其欣赏书中对于“领域事件”的讲解。过去,我们常常通过直接调用来处理业务流程中的各个环节,这种方式容易造成紧耦合,一旦某个环节发生变化,整个流程都可能受到影响。而引入领域事件,则提供了一种异步、解耦的通信方式,让系统更具弹性和可扩展性。想象一下,当一个“订单已创建”的事件发生时,不同的服务可以各自响应,比如通知库存系统、支付系统、物流系统等等,而它们之间无需直接感知对方的存在。这种设计思想,彻底改变了我对系统间通信的看法。这本书的语言虽然是英文,但作者的表达清晰流畅,结构也非常合理,即使是对于非母语读者来说,也并不构成太大的障碍。它教会我如何用更少的代码实现更强大的功能,如何构建一个真正面向业务、易于演进的软件系统。
评分说实话,一开始被《实现领域驱动设计》这本书的厚度吓了一跳,以为会是一本晦涩难懂的学术著作。然而,在深入阅读后,我发现它远比我想象的要实用和易懂得多。这本书并非是教你如何写出“炫酷”的代码,而是教你如何写出“聪明”的代码,如何让代码真正反映业务的本质。书中对于“充血模型”和“贫血模型”的讨论,让我对过去的一些设计决策有了新的认识。我们过去常常习惯于将业务逻辑放在服务层,而领域模型仅仅是数据的载体。这种“贫血模型”虽然在初期开发可能显得效率高,但随着业务逻辑的复杂化,维护起来会变得非常困难。这本书强调将业务逻辑内聚在领域模型中,让领域对象拥有自己的行为,从而构建一个更具表现力和可维护性的系统。这不仅仅是一种编码风格的改变,更是一种对软件设计理念的重塑。它让我明白,软件不仅仅是代码,更是对业务领域知识的体现。这本书的价值在于,它提供了一套经过实践检验的、能够帮助我们构建更健壮、更易于演进的软件系统的思想和方法。
评分坦白说,在翻开《实现领域驱动设计》这本英文原版之前,我对“领域驱动设计”(DDD)这个概念其实是有些模糊的。听过一些讲座,看过一些零散的文章,总觉得有些抽象,难以落地。这本书的出现,就像是在一片迷雾中点亮了一盏灯。它没有直接抛出晦涩难懂的术语,而是通过大量的案例和循序渐进的讲解,将DDD的核心思想一点一点地剖析开来。最让我印象深刻的是关于“领域模型”的阐述。过去,我们习惯于将数据模型和业务逻辑混为一谈,导致模型臃肿且难以理解。而这本书强调,领域模型应该是业务的核心,是软件的灵魂。它不仅仅是数据库的表结构,更是对业务领域知识的深度提炼和抽象。书中对“聚合”、“实体”、“值对象”等概念的解释,让我明白了如何构建一个清晰、有生命力的领域模型。我开始尝试在自己的项目中运用这些概念,虽然起初有些生涩,但很快就体会到了其带来的好处。代码的可读性大大提高,业务逻辑也变得更加清晰。这本书不是那种看完就能立即成为专家的秘籍,它需要时间和实践去消化和领悟。但它提供了一个坚实的基础和一套行之有效的方法论,让我能够以一种更系统、更专业的方式去思考和设计软件。
评分书质量不错~~~值得购买
评分还行了
评分早就想买,刚到手
评分书不错,但这个包装也太差了,表面灰尘和摩擦痕迹非常严重,擦了好久都不干净,相当于二手书了,不过书能看也懒得折腾了
评分还行了
评分早就想买,刚到手
评分书不错,但这个包装也太差了,表面灰尘和摩擦痕迹非常严重,擦了好久都不干净,相当于二手书了,不过书能看也懒得折腾了
评分除了贵没毛病
评分除了贵没毛病
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 book.cndgn.com All Rights Reserved. 新城书站 版权所有