DDD 模型

前端之家收集整理的这篇文章主要介绍了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仅仅是领域事件的技术延伸物,不是唯一的、终极的 所以,系统架构作为领域模型的衍生物而存在,不能侵入领域模型,没必要刻意去分动词、名词之类,这些都是一些技巧、方法论,非本质思想!!!

原文链接:https://www.f2er.com/javaschema/286048.html

猜你在找的设计模式相关文章