序
前言
緻謝
關於作者
如何使用本書、
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.tinynews.org All Rights Reserved. 静思书屋 版权所有