#1 DDD

#2 Cache Resource

#3 3 main Book

Domain-Driven Design: Trackling Complixity in the Heart of Software - Eric Evans

Implementing Domain-Driven Design - Vaughn Vernon
Domain-Driven Design Distilled - Vaughn Vernon

DDD Website:

domainlanguage.com - Eric Evans (So many resource, books, videos, training )

#3 Other Books

Domain-Driven Design in PHP

Patterns, Principles, and Practices of Domain-Driven Design
The Anatomy Of Domain-Driven Design - Booklet
The Anatomy Of Domain-Driven Design
Principles, Patterns and Practices of Domain-Driven Design
Head First Domain-Driven Design
Domain-Driven Design Quickly
JavaScript Domain-Driven Design
Domain-Driven Design Using Naked Objects
Domain Driven Design: How to Easily Implement Domain Driven Design - A Quick &
Simple Guide
Language Implementatino Patterns
Domain Modeling Made Funcitonal - F#
Domain-Driven Design All-Inclusive Self-Assessment - More than 640 Success Criteria,
Instant Visual Insights, Comprehensive Spreadsheet Dashboard, Auto-Prioritized for
Quick Results
Domain-Specific Development of Event Condition Action Policies
DDD dla architektow oprogramowania
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
Domain-Driven Design Complete Self-Assessment Guide

#3 CQRS
 CQRS, The example

Exploring CQRS and Event Sourcing (Microsoft patterns & practices)

#3 Video Course

系列视频The Animated Anotomy od DDD

Domain-Driven Design Distilled LiveLessons

Distilling Domain-Driven Design

Moving to Microservices: Using Domain-Driven Design to Break Down the Monolith

LiveLessons

#3 DSL

DSL Engineering: Designing, Implementing and Using Domain-Specific Languages

DSL in Action

Domain-Specific Languages

Implement Domain Specific Languages with Xtext and Xtend

Language Implementatino Patterns

#3 Conf

Steven A. Lowe - Three Rules for Domain-Driven Design

Explore DDD - official website

#3 Slide - Build Complex Domains in Rails

slide-link

video-link
#3 Couser for comprehension course

link

#3 Other

valignatev/ddddynamic

#2 Learning Flow

#3 Wiki - Domain-driven design

en.wikipedia.org/wiki/Domain-driven_design

创始⼈: Erirc Evans

其运营的官⽹： domainlanguage.com

官⽹上有付费的⽜逼课程，准备购买

⼜看到另⼀篇⽂章: 今天我们还需要关注DDD吗?

了解到DDD是微服务，Eventstorm的⿐祖. 这⾥有⼏个重要实现与其对应的⼈：

DDD 以及创始⼈ Erirc Evans

Implementing Domain-Driven Design 以及作者 Vaughn Vernon
微服务 以及关键⼈物Martin Fowler
CQRS
EventStorming 以及创始⼈ Alberto Brandolini

在ruby china的⼀个帖⼦的讨论中，提到⼀种思路，就是可以去借鉴Hanami, Trailblazer,

Dry-ruby, ROM的思路，反向⽤进Rails项⽬中去

(wiki还没看完)⾥⾯讲了很多其他的design idea.

#3 domainlanguage.com elearning Course

已付费，开始学习domainlanguage.com - elearning
#4 Maps and Models

Assertions are a key aspect of the model: "direction between points are preserved in the projection"

Characteristics of models

focus only on relevant information

formalize our thinking
make assertions about result

the angle between any 2 points corresponds to a compass heading

A model is a system of abstractions

Addresses a subset of information about the domain.

Specialized, rather than general

Models are artificial

#4 DDD Walk through

Model Definitions

Domain: A sphere of knowledge or activity.

Model: A system of abstractions representing selected aspects of a domain

Usefulness of models

model is not about realism

Choose a model that's suited to the purpose at hand.

Thee will be more than one model in use.

有些时候⼀个好好的锤⼦，被改成锤⼦，锯⼦两⽤的 .

#4 Aggregates

An Aggretate is a part of the model

Chosen Aggregates guide our technical decisions:

constrains what's included in transactions

 indicates our options for concurrent processing
gives constraints on distribution

#4 Collaboration

Focus on the Ubiquitous Language

Challenge assumptions.
Cultivate a strong relationship with the domain expert.

#4 Bounded Context Intro

Context: The setting in which a word or statement appears that determines its meaning

Bounded Context: The condition under which a particular model is defined and
applicable.

Map what it is .

不⽤做⼀个完美的Context,遇到什么问题，就建⽴什么context

#4 Context Mapping I

Upstream-Donwstream

Upstream的成功与否会影响Downstream

Donwstream的成功与否不会影戏那个Upstream

The upstream team may succeed independently of the fate of the downstream team.
Customer/Supplier Development

A downstream team can be helpless, at the mercy of upstream priorities. Meanwhile, the
upstream team may be inhibited, worried about breaking downstream systems. The
problems of the downstream team are not improved by cumbersome change request
procudures with complex approval processes. And the freewheeling development of the
upstream team will stop if the downstream team has veto power over changes.

Establish a clear customer/supplier relationship between the two teams, meaning

downstream priorities factor into upstream planning. Negotiate and budget tasks for
downstream requirements so that everyone understands the commitment and schedule.

最后应该这样:
 需要时刻问⾃⼰ Which ubiquite languge should you use?

说⽩了就是，你在哪⼀个context⾥（或哪⼀层），你就应该⽤哪⼀个context的ubiquate
language

#4 Distilling Core Domain

Generic subsomains
Supporting subsomains
Core domain

#3 TOC of all books

#3 Book - DDD

The premise of this book:

For most software projects, the primary focus should be on the domain and domain
logic.
Complex domain designs should be based on a model

Two practices are prerequisites for applying the approach in this book:
 Development is iterative
Surviving Object-Oriented Projects
Extreme Programming Explained
Developers and domain experts have a close relationship

The XP process assumes that you can improve a design by refactoring, and that you will
do this often and rapidly.

但是开发者技术和理解的参差不⻬，导致之后的交流越来越困难，因为每次的refactoring会朝
着不同的⽅向发展，不⼀定是好事。所以DDD估计是来解决这种交流问题和保证refacotring的
⼀致性

Books Structure:

Part I: Putting the Domain Model to Work

主要是Overview
Part II: The Building Blocks of a Model-Driven Design
主要是Focus on bridging the gap between models and practical, running software.
开发者都是⽤这种standard patterns会⽅便交流，提供更通⽤的术语
The main point of this secion is to focus on the kins of decisions that keep the model
and implementation aligned with each other, each reinforcing the other's
effectiveness.
学好了这⾥⾯的Pattern了以后，就可以更好的使⽤后⾯抽象级别更⾼的modeling
approaches.
Part III: Refactoring Toward Deeper Insight goes
知道我们如何有⽅法的进⾏refactor探索. 也就是探索的模型，探索的⽅法
Part IV: Strategic Design

#4 Part I: Putting the Domain Model to Work

Maps are models, and every model represents some aspect of reality or an idea that is of
interest.

A model is an interpretation of reality that abstracts the aspects relevant to solving the
problem at hand and ignores extraneous detail.

The Utility of a model in Domain-Driven Design

1. The model and the heart of the design shape each other
2. The model is the backbone of a language used by all team members
3. The model is distilled knoledge

#5 Chapter 1: Crunching Knowledge

Ingredients of Effective Modeling

 1. Binding the model and implementation.
2. Cultivating a language based on the model.
3. Developing a knowledge-rich model.
⼀个Model需要具有完整解决⼀个问题的能⼒
4. Distilling the model.
现有的Model不⼀定完美，有时可能需要从中萃取出⼀个全新的Model
5. Brainstorming and experimenting.
多⼈⼝述表达，就是在验证Model的可⾏性，我猜EventStorm应该属于这⼀块

Knowledge Crunching

意思我们要像Domain experts⼀样，甚⾄和他们⼀起，不断去打磨⾃⼰的认知，然后使⽤通
⽤的想法和视⻆来进⾏开发

Effective domain modelers are knowledge crunchers.

Continuous Learning

提到⼀本书 practicing continuous learning (Kerievsky 2003) 感觉是说团队需要持续学习

要学会如何跟Domain Exports交流，要持续互相学习

Knowledge-Rich Design

⽬的就是要做⼀个more explicit design.

抽出适当的逻辑 （要考虑，其他⼈是否能看懂）

1. In order to bring the design to this stage, the programmers and everyone else involved
will have come to understand the nature of overbooking as a distinct and important
business rule, not just an obscure calculation.
2. Programmers can show business experts technical artifacts, even code, that should be
intelligible to domain experts (with guidance), thereby closing the feedback loop.

Deep Models

最初的domain设计很可能是错的或者过于局限，要与domain⼀起探讨更多以后，再进⾏更完
整的设计

#5 Chapter 2: Communication and the Use of Language

This model-based communication 需要遍布整个交流过程，不局限于UML

Ubiquitous Language

⼀般情况下Domain exports使⽤他们的jargon, Developer也使⽤⾃⼰的jargon,但是项⽬中很

少有bilingual的

所以使⽤通⽤语⾔是很重要的。

这⾥⾯有⼀段对话演⽰和⽐较，⾮常有意思。基本上就是要把那些关键的concept都抽象为
model放在图中，然后交流的时候持续使⽤他们交流。说⽩了就是要把开发和交流对接起来，
这个对接就是model的定义，model承载了两重作⽤。

Modeling Out Load

One Team One Laguange

左右两边都是extensions to the ubiquitous language.

Documents and Diagrams

The model is not the diagram. The diagram's purpose is to help communicate and
explain the model.

Written Design Documents

 Documents Should Complement Code and Speech

A documnet shouldn't try to do what the code already does well. Document Should Work
for a Living and Stay Current.

问题：这种⽂档神恶魔时候写，⻓什么样⼦，它的粒度是什么？

Explanatory Models

#5 Chapter 3: Binding Model and Implementation

MODEL - DRIVEN DESIGN discards the dichotomy of analysis model and design to search
out a single model that serves both purposes. Setting aside purely technical issues, each
object in the design plays a conceptual role described in the model. This requires us to
be more demanding of the chosen model, since it must fulfill two quite different
objectives.

Development becomes an iterative process of refining the model, the design, and the
code as a single activity

Modeling Paradigms and Tool Support

Letting the Bones Show: Why Models Matter to Users

这⾥⾯看到⼀个很好的案例。关于浏览器favariot的功能报错问题

⼀个错误以及错误信息 都应该只存还在其 同⼀抽象级别或者同⼀个场景内容，如果要超出这

个场景，⼀定要重新包装。也就是说model分层对异常信息的传递也⼀样要考虑。甚⾄是要多
重报错，对开发者报⼀个详细的多层的错。 对⽤⼾只报单独⼀⾯其看得懂的友好的错。
 Hands-On Modelers

#4 Part II: The Building Blocks of a Model-Driven Design

The design style in this book largely follows the principle of “responsibility-driven
design,” put forward in Wirfs-Brock et al . 1990 and updated in Wirfs-Brock
2003. It also draws heavily (especially in Part III) on the ideas of “design by contract”
described in Meyer 1988. It is consistent with the general background of other widely
held best practices of object-oriented design, which are described in such books as
Larman 1998.

#5 Chapter 4: Isolating the Domain

Communication upward must pass through some indirect mechanism.

Layered Architecture

User Interface (or Presentation Layer)

Application Layer
This layer is kept thin. It does not contain business rules or knowledge, but only
coordinates tasks and delegates work to collaborations of domain objects in the next
layer down. It does not have state reflecting the business situation, but it can have
 state that reflects the progress of a task for the user or the program.
Domain Layer (or Model Layer)
This layer is the heart of business software
Infrastructure Layer
message sending, persistence of domain, drawing widgets for the UI...
may also support the pattern of interactions between the four layers through an
architectural framework

layuer只能往⼀个⽅向流, 如果lower layer要与 high layer交流，只能通过callback或

observer (也就是mesage⼴播)

The Domain Layer is where the model lives

The Smart UI "Anti-Pattern"

这个不适合DDD

#5 Chapter 5: A model Expressed in Software

Associations

不是很明⽩想说什么

关系的双向 不⼀定要在domain⾥出现，根据情况，可设置为单向的，还可以加限制条件

Entities (A.K.A. Reference Objects)

An object defined primarily by its identity is called an ENTITY.

#3 Slide

#4 Built to last: A domain-driven approach to beautiful systems by Andrew

hao

RailsConf 2017: Built to last: A domain-driven approach to beautiful systems by Andrew

Hao

slide
正常的MVC+services的样⼦:

通⽤语⾔:

user.request_trip => passenger.hail_driver

Visualize Your System

可以先使⽤railroady 和 rails-erd来输出初始数据

Core domain

找出Core domain

如: Transportation

Supporting Domians

找出Supporting Domain

如：

Driver Routing (route me from X to Y)

Financial Transactions (charge the card, pay the driver)
Optimization & Analytics (track business metrics)
Customer Support (keep people happy)

Bounded Context
Draw out the dependencie

Upstream/Downstream

An Ideal Architecture

Each Domain should have its own Bounded Context

Break your application into domain modules

class Trip < ActiveRecord::Base

belongs_to :vehicle
belongs_to :passenger
belongs_to :driver
end

class TripsController < ApplicationController

# ...
end

module RideSharring
class Trip < ActiveRecord::Base
belongs_to :vehicle
belongs_to :passenger
belongs_to :driver
end
end

module Ridesharing
class TripsController < ApplicationController
 # ...
end
end

# config/routes.rb
resources :trips

class Invoice
belongs_to :trip
end

Passing around Aggregate Roots

class PaymentConfirmation
belongs_to :trip, class_name: Ridesharing::Trip
belogns_to :passenger, class_name: Ridesharing::Passenger
belongs_to :credit_card
has_many :menu_items
belongs_to :coupon_code
has_one :email_job
# ad infinitum
end

Aggregate Root are top-level domain models that reveal an object graph of related
entities beneath them.

Only expose aggregate roots

Make it a rule that each domain only exposes Aggregate Root(s)

publicly via:

Direct method calls

JSON payloads
API endpoints
Build service objects that provide Aggregate Roots

Break dependencies on AactiveRecord relationships

Your source domain can provide a service that returns the Aggregate Root as a facade

# Provide outside access to a core model for the Ridesharing domain

module Ridesharing
class FetchTrip
def call(id)
Trip
.includes(:passenger,
:driver, ...)
.find(id)
# Alternatively, return something non-AR
# OpenStruct.new(trip: trip.find(id)....)
end
end
end

# In the old world, we relied on AR relationships:

module FinancialTransaction
class PaymentConfirmation
belongs_to :trip, class_name: Ridesharing::Trip
belongs_to :passenger, class_name: Ridesharing::Passenger
# ....
end
 end

# Now, cross-domain fetches must use the aggregate root servide:

module FinacialTransaction
class PaymentConfirmation
def trip
# Returns the Trip aggregate root
Ridesharing::FetchTrip.new.find(payment_id)
end
end
end

# OLD: payment_confirmation.passenger
# New: payment_confirmation.trip.passenger

#4 Domain Driven Rails -Yan Pritzker

Domain Driven Rails - Yan Pritzker

video

这个⼈是dotenv的作者

把 UsersControler#forgot_passoword ⾥的代码refactor
到 Accounts::ForgotPassword.send_password_reset

Naming

不使⽤ OrderService

⽽是使⽤ ShipOrder , RefundOrder , CancelOrder

Role (也就是Domain Model)

class InventoriedListing < DelegateClass(Listing) end

class TaxableOrder < DelegateClass(Order) end

Events
 不使⽤callback

使⽤ Wisper Publisher

Policy Objects

这个实际上就是使⽤以来倒转的⽅法,把这种Policy的内容抽象出去

#3 Learn with theme

#3 Bounded Context

A bounded context is not a Module. A bounded Context provides the logical frame inside
of which the model evolves. Modules are used to organize the elements of a model, so
Bounded Context encompasses the Module.

It is much simpler for the e-shop application to send Value Objects containing purchase
information to the warehouse using asynchronous messaging.

#4 Communicating Between Bounded Contexts

This kind of decoupling is critical if we want to have truly autonomous components.

#4 Transferring Data Between Bounded Contexts

 Data Transfer Objects (DTO).

它与bounded context⾥的Domain Objects类似，但并不是同⼀类东西， it will structured

differently to suit its purpose. 应该是与Serialization有关:

At the boundaries of the upstream context then, the domain objects are converted into
DTOs, which are ini turn serialized into JSON, XML, or some other serialization format.

At the downstream context, the process is repeated in the other direction: the JSON or
XML is deserialized into a DTO, which in turn is converted into a domain object:

In practive, the to-level DTOs that are serialized are typically Events DTOs, which in turn
contain child DTOs such as a DTO for Order, which in turn contains additional child DTOs
(e.g. a list of DTOs representing OrderLines.)

#4 Trust Boundaries and Validation

每个进⼊Boundaries的DTO都需要经过⼀层Validation验证

output也有⼀层验证
 The job of the output gate is to ensure that private information doesn't leak out of the
bounded context, both to avoid accidental coupling between contexts, and for security
reasons.

不过与其说是验证，不如说是作为⼀个最后的输出层，也就是serialize层就够了

作者的意思应该是把validation与serialization分开

#4 Contracts Between Bounded Contexts

Bounded context之间交流的format会induces some coupling. 也就是我们要在⼀个地⽅来决

定这个format是什么，不能什么都不说，这样属于隐藏的坑

对内,或对外

Shared Kernel : two contexts share common domain desgin.

Cutomer/Supplier or Consumer Driven Contract: downstream context
defineds the contract that they want the upstream context to provide.
Conformist : The downstream context accepts the contract provided by the
upstream context.
对外

Anti-Corruption Layer (ACL) : acts as a translator between two different

language (Upstream and Downstream). Use it when the interface that is available
does not match our domain model at all.

#4 A context Map with Relationships

把上⾯四种综合起来，放在⼀起看
 Shipping and Order-taking use a jointly own the communications contract
Order-taking and Billing: Billing defined the contrast
顺着⽅向说：客⼾你是上帝，你说了算
Order-taking and Production CataLog: Product CataLog defined the contrast
顺着⽅向说：你给我好好遵守
Order-taking and Address Checking: we insert an ACL to deal with transalte. It helps us
avoid vendor lock-in, and lets us swap to a different service later.

#4 Workflows Within a Bounded Context

Workflow开始与⼀个Command,然后经过Bounded Context以后就会generated one or

more domain events.

Input is always the data associated with a command

Output is always a set of events to communicate to other contexts

这个的实现上需要再看看具体怎么实现的

#4 Code Structure within a Bounded Context

#4 The Onion Architecture
 与Onion Architecture类似的有 Hexagonal Architecture , Clean Architecture

#4 Keep I/O at the Edges

有⼀点Funcitonal的思路在⾥⾯

对读写Database的功能，不要写在workflow中间，应该写在两头

To push any I/O to the edges of the onion - to only access a database at the start or end of
a workflow, but not inside the workflow

#4 DTOs Instead of Model instances in View (DDD in PHP)

The View layer receives an object, often a Data Transfer Object(DTO) insteand of
instances of the Model layer, gathering all the needed information to be successfully
represented.

#4 Integration˜Relationsihp of Bounde Context (DDD in PHP)

不推荐Shared Kernel 因为两边都要交流，两边都要维护。

Customer/Supplier ⾥的的测试应该是要写在UpStream这⼀边，来确定⾃⼰是否满⾜
downstream的要求

Jointly develop automated acceptance tests that will validate the interface expected. Add
these tests to the upstream team’s test suite, to be run as part of its’ continuous
integration. This testing will free the upstream team to make changes without fear of side
effects downstream.

Conformist 注意在⼀侧要使⽤ UBIQuitous language, Conformist 感觉更像直接让其⾛⼊进

来的感觉(还不是很懂)

#4 Bounded Context Pattersn (DDD using Naked Objects)

Every bounded context contans a single domain model, but the idea of a bounded
context is to make explicit the relationship between one system and another.

#4 Scaling up DDD Projects (DDD and Patterns in C#)

这⾥提到bouded context的另⼀个好处，是可以很容易的去划分团队，每个团队做它⾃⼰需要
做的事，⾮常清晰

#4 Use Bounded Contexts to divide and conquer a large model

下⾯这个图还不是很懂，可能要了解⼀下Subdomain 才⾏
还提到并不⼀定每⼀个boundd context⾥都要同样的构架，可以⽤不同的构架，根据需求和
复杂度来决定，可以看下图：

A Composite UI is a user interface made up of loosely coupled components. A composite

UI shows data from multiple bounded contexts on the same web page. This can be dones
with multiple Ajax calls, for example.
 这个时候就可以祭出service了，看来这个才是service的⽤武之地. - Application Services

Subdomain are used in the problem space to partition the problem domain. Bounded
contexts are used to defined the applicability of a model in the solution space.
A single team should own a bounded context.
Architectural patterns apply at the bounded context level, not at the application level.
If you don't have complex logic in a bounded context, use a simple CRUD architecture.
Speak a ubiquitous language within an explicitly bounded context.
A bounded context should be autonomous - owning the entire code stack from
presentation through domain logic and onto the database and schema.

#3 Aggregate

#3 Subdomain

#3 Context Mapping