实现领域驱动设计（英文版）

目录序前言致谢关于作者如何使用本书、Chapter

Getting

Started

with

DDDCan

I

DDD?Why

You

Should

Do

DDDHow

to

Do

DDDThe

Business

Value

of

Using

DDD1.

The

Organization

Gains

a

Useful

Model

of

Its

Domain2.

A

Refined,

Precise

Definition

and

Understanding

of

the

Business

Is

Developed3.

Domain

Experts

Contribute

to

Software

Design4.

A

Better

User

Experience

Is

Gained5.

Clean

Boundaries

Are

Placed

around

Pure

Models6.

Enterprise

Architecture

Is

Better

Organized7.

Agile,

Iterative,

Continuous

Modeling

Is

Used8.

New

Tools,

Both

Strategic

and

Tactical,

Are

EmployedThe

Challenges

of

Applying

DDDFiction,

with

Bucketfuls

of

RealityWrap-UpChapter

Domains,

Subdomains,

and

Bounded

ContextsBig

PictureSubdomains

and

Bounded

Contexts

at

WorkFocus

on

the

Core

DomainWhy

Strategic

Design

Is

So

Incredibly

EssentialReal-World

Domains

and

SubdomainsMaking

Sense

of

Bounded

ContextsRoom

for

More

than

the

ModelSize

of

Bounded

ContextsAligning

with

Technical

ComponentsSample

ContextsCollaboration

Context.Identity

and

Access

Context.Agile

Project

Management

ContextWrap-UpChapter

Context

MapsWhy

Context

Maps

Are

So

EssentialDrawing

Context

MapsProjects

and

Organizational

RelationshipsMapping

the

Three

ContextsWrap-UpChapter

ArchitectureInterviewing

the

Successful

CIOLayersDependency

Inversion

PrincipleHexagonal

or

Ports

and

AdaptersService-OrientedRepresentational

State

Transfer—RESTREST

as

an

Architectural

StyleKey

Aspects

of

a

RESTful

HTTP

ServerKey

Aspects

of

a

RESTful

HTTP

ClientREST

and

DDDWhy

REST?Command-Query

Responsibility

Segregation,

or

CQRSExamining

Areas

of

CQRSDealing

with

an

Eventually

Consistent

Query

ModelEvent-Driven

ArchitecturePipes

and

FiltersLong-Running

Processes,

aka

SagasEvent

SourcingData

Fabric

and

Grid-Based

Distributed

ComputingData

ReplicationEvent-Driven

Fabrics

and

Domain

EventsContinuous

QueriesDistributed

ProcessingWrap-UpChapter

EntitiesWhy

We

Use

EntitiesUnique

Identity.User

Provides

IdentityApplication

Generates

IdentityPersistence

Mechanism

Generates

IdentityAnother

Bounded

Context

Assigns

IdentityWhen

the

Timing

of

Identity

Generation

MattersSurrogate

IdentityIdentity

Stability.Discovering

Entities

and

Their

Intrinsic

CharacteristicsUncovering

Entities

and

PropertiesDigging

for

Essential

BehaviorRoles

and

ResponsibilitiesConstructionValidationChange

TrackingWrap-UpChapter

Value

ObjectsValue

CharacteristicsMeasures,

Quantifies,

or

DescribesImmutableConceptual

WholeReplaceabilityValue

Equality.Side-Effect-Free

BehaviorIntegrate

with

Minimalism.Standard

Types

Expressed

as

ValuesTesting

Value

ObjectsImplementation.Persisting

Value

ObjectsReject

Undue

Influence

of

Data

Model

Leakage.ORM

and

Single

Value

ObjectsORM

and

Many

Values

Serialized

into

a

Single

ColumnORM

and

Many

Values

Backed

by

a

Database

Entity.ORM

and

Many

Values

Backed

by

a

Join

Table.ORM

and

Enum-as-State

ObjectsWrap-UpChapter

ServicesWhat

a

Domain

Service

Is

(but

First,

What

It

Is

Not)Make

Sure

You

Need

a

Service.Modeling

a

Service

in

the

DomainIs

Separated

Interface

a

Necessity?A

Calculation

ProcessTransformation

Services.Using

a

Mini-Layer

of

Domain

ServicesTesting

Services.Wrap-UpChapter

Domain

EventsThe

When

and

Why

of

Domain

EventsModeling

EventsWith

Aggregate

CharacteristicsIdentityPublishing

Events

from

the

Domain

ModelPublisherSubscribersSpreading

the

News

to

Remote

Bounded

ContextsMessaging

Infrastructure

ConsistencyAutonomous

Services

and

SystemsLatency

TolerancesEvent

StoreArchitectural

Styles

for

Forwarding

Stored

EventsPublishing

Notifications

as

RESTful

ResourcesPublishing

Notifications

through

Messaging

MiddlewareImplementationPublishing

the

NotificationLogPublishing

Message-Based

NotificationsWrap-UpChapter

ModulesDesigning

with

ModulesBasic

Module

Naming

ConventionsModule

Naming

Conventions

for

the

Model.Modules

of

the

Agile

Project

Management

ContextModules

in

Other

LayersModule

before

Bounded

ContextWrap-UpChapter

AggregatesUsing

Aggregates

in

the

Scrum

Core

DomainFirst

Attempt:

Large-Cluster

AggregateSecond

Attempt:

Multiple

AggregatesRule:

Model

True

Invariants

in

Consistency

BoundariesRule:

Design

Small

AggregatesDon’t

Trust

Every

Use

CaseRule:

Reference

Other

Aggregates

by

IdentityMaking

Aggregates

Work

Together

through

IdentityReferencesModel

NavigationScalability

and

DistributionRule:

Use

Eventual

Consistency

Outside

the

BoundaryAsk

Whose

Job

It

IsReasons

to

Break

the

RulesReason

One:

User

Interface

ConvenienceReason

Two:

Lack

of

Technical

MechanismsReason

Three:

Global

TransactionsReason

Four:

Query

PerformanceAdhering

to

the

RulesGaining

Insight

through

Discovery.Rethinking

the

Design,

AgainEstimating

Aggregate

CostCommon

Usage

ScenariosMemory

ConsumptionExploring

Another

Alternative

DesignImplementing

Eventual

Consistency.Is

It

the

Team

Member’s

Job?Time

for

DecisionsImplementationCreate

a

Root

Entity

with

Unique

IdentityFavor

Value

Object

PartsUsing

Law

of

Demeter

and

Tell,

Don’t

AskOptimistic

Concurrency.Avoid

Dependency

Injection.Wrap-UpChapter

FactoriesFactories

in

the

Domain

ModelFactory

Method

on

Aggregate

RootCreating

CalendarEntry

InstancesCreating

Discussion

InstancesFactory

on

ServiceWrap-UpChapter

RepositoriesCollection-Oriented

RepositoriesHibernate

ImplementationConsiderations

for

a

TopLink

ImplementationPersistence-Oriented

RepositoriesCoherence

ImplementationMongoDB

ImplementationAdditional

BehaviorManaging

TransactionsA

WarningType

HierarchiesRepository

versus

Data

Access

ObjectTesting

RepositoriesTesting

with

In-Memory

ImplementationsWrap-UpChapter

Integrating

Bounded

ContextsIntegration

BasicsDistributed

Systems

Are

Fundamentally

DifferentExchanging

Information

across

System

BoundariesIntegration

Using

RESTful

ResourcesImplementing

the

RESTful

ResourceImplementing

the

REST

Client

Using

an

Anticorruption

LayerIntegration

Using

MessagingStaying

Informed

about

Product

Owners

and

Team

MembersCan

You

Handle

the

Responsibility?Long-Running

Processes,

and

Avoiding

ResponsibilityProcess

State

Machines

and

Time-out

TrackersDesigning

a

More

Sophisticated

ProcessWhen

Messaging

or

Your

System

Is

UnavailableWrap-UpChapter

Application.User

InterfaceRendering

Domain

Objects

Render

Data

Transfer

Object

from

Aggregate

InstancesUse

a

Mediator

to

Publish

Aggregate

Internal

StateRender

Aggregate

Instances

from

a

Domain

Payload

Object

State

Representations

of

Aggregate

InstancesUse

Case

Optimal

Repository

Queries.Dealing

with

Multiple,

Disparate

ClientsRendition

Adapters

and

Handling

User

EditsApplication

ServicesSample

Application

ServiceDecoupled

Service

OutputComposing

Multiple

Bounded

ContextsInfrastructureEnterprise

Component

ContainersWrap-UpAppendix

A

Aggregates

and

Event

Sourcing:

A+ESInside

an

Application

ServiceCommand

HandlersLambda

SyntaxConcurrency

Control.Structural

Freedom

with

A+ESPerformanceImplementing

an

Event

StoreRelational

PersistenceBLOB

PersistenceFocused

AggregatesRead

Model

ProjectionsUse

with

Aggregate

DesignEvents

EnrichmentSupporting

Tools

and

PatternsEvent

SerializersEvent

ImmutabilityValue

ObjectsContr