DDD 模型

http://www.jdon.com/44986

人们对动词的敏感远远高于静止的事物。比如我们要开发一个软件系统，对于软件功能function，能够做什么非常关心。

功能如此非常重要，以至于人们分析需求时，可能只看到动词功能，而忽视需求中静止的结构本质与边界；而基于数据库的技术则是试图以静止的数据结构Schema来实现功能，这两者强行结合，造成了程序员编程热衷于用数据库的SQL的CRUD来实现需求功能，而设计的数据表库结构可能不能反映需求中静止的结构。

我们需要一种方法能够进行动词名词综合平衡，不能只看到动词忽略名词，也不能因为名词忽略动词。

在我们OO分析需求建模过程中，动词和名词的分离是一条主要线索，动词名词进行分离，还要再结合验证，如下图Jdon分析法：


横向坐标是动词，以事件为主要线索；纵坐标是以名词静止的结构为主要线索。它们之间的结合是状态。

功能如此非常重要，以至于人们分析需求时，可能只看到动词功能，而忽视需求中静止的结构本质与边界；而基于数据库的技术则是试图以静止的数据结构Schema来实现功能，这两者强行结合，造成了程序员编程热衷于用数据库的SQL的CRUD来实现需求功能，而设计的数据表库结构可能不能反映需求中静止的结构。”，时至现在仍然有这样的现象，在前几年有个代码自动生成器，生成的代码可以说是典型的SQL式的CRUD，其使用者不乏其人。一个项目执行的任何命令其本质上是CRUD之一但他的上下文环境边界的界定，分析，适应需求变化的敏捷性设计，更像门艺术活，需要精雕细琢才行。

既然动词是个独裁者，如此突出显式，不妨可以直接面对它。 动词也是由内外两个部分组成：动词名称本身和动词对外部造成的影响。

动词如此突出，关键是动词对整个语句，也就是对外部造成的影响如此让人印象深刻。那么我们何妨抓住动词这个要点，起到纲举目张的效果？

以事件这个动词为例子，事件分两种含义，或者说从两个角度分别看到两种含义：

一种是事件名词本身，比如创建事件 销毁事件 响铃事件，创建 销毁和响铃本身是一个对象，可以看成一种实体，可以被持久被保存，也可以被追溯，这个角度就是Event Sourcing。

事件另外一种角度是：事件对外部周围环境产生影响和效果，事件改变了聚合根的状态。从这个角度看，事件是一种Domain Events。

所以，一个事件既可以是Event Sourcing，又可以是Domain Events。事件贯穿于整个系统或领域层，如此重要，如此独裁，我们不能不忽视，更要分解之。

所以，一个事件既可以是Event Sourcing，又可以是Domain Events。事件贯穿于整个系统或领域层，如此重要，如此独裁，我们不能不忽视，更要分解之。 ...

Event Sourcing可以是系统需求、技术实现，但不是领域需求，Domain Event却明确存在于领域模型之中，系统的任何技术需求都伴随特定模型领域特征（聚合根、事件等）的出现自然而然的呈现出来，这一点与物种进化应该是一个道理，生物基因突变出现特定的性状特性，由特定形状的出现进而演化出一套进攻或防御系统，换言之，进攻或防御系统是不可能凭空出现必须拥有特定的物质基础。

Event Sourcing或CQRS仅仅是领域事件的技术延伸物，不是唯一的、终极的

所以，系统架构作为领域模型的衍生物而存在，不能侵入领域模型，没必要刻意去分动词、名词之类，这些都是一些技巧、方法论，非本质思想！！！