领域模型驱动(DDD)之我见

粗看了一遍《领域驱动设计》感觉是它要统一江湖。领域驱动设计以下简称DDD。

软件开发流程基本上是：需求收集-分析-设计-编码-测试-部署-维护。这几个阶段应该没什么歧义。

DDD 引入了业务专家。这没什么疑问。软件目标是产生价值。当软件的呈献符合行业规则的时候，业内人能更好的操作软件。

DDD 分了战略和战术。

战略工具包括，

• 核心域
• 扩展域
• 支撑域
• 通用语言
• 上下文章映射

以我粗浅的理解，

这些个域和分析阶段的子系统划分、模块划分类似。

通用语言应对之前的术语表或者关键概念抽象。

上下文章映射对于UML包图的包间依赖。

区别在于DDD的划分是站在了业务(软件价值)的角度。

分析和设计阶段的技术(架构，设计模式，设计原则)目的是可重用软件，DDD的目标则是有价值软件。

“各种软件开发流程和技术的终极目标是高效产出高质量软件”相信这句话应该没人反驳。感觉DDD侧重价值发现。各种域确定了资源分配(不存在无限资源的团队)

也因为DDD和之前掌握的技能是观点(角度)方面的差异，所以之前掌握的技能可以用于DDD。DDD不是革命也算不上创新，只是提供了一个新视角。

战术工具包括，

• 聚合根
• 工厂
• 事件驱动
• 模块

聚合根相当于软件设计中的，组合、聚合优于继承。

工厂不用说对应GOF中的工厂模式没什么疑问。

事件驱动也不算什么新的内容。Windows就是事件驱动的。

模块相当于UML中层级相对低的包图。

还是那句话，东西还是原来的东西，DDD是从价值的角度在观察。

在UML中，模型与视图的关系。软件开发中的要件相当于模型，DDD提供了视图的一个侧面。

那，这个侧面有什么价值呢？是否与软件的“可重用”目标冲突呢？

我认为不冲突。

在DDD的价值观下，它把原来分散的技术要点组合起来了。eg: 用例，分析框架，设计模式，测试。所有这些步骤以业务价值为导向。这也是我所说的它要统一江湖的原因。

DDD还强调抽象出一个“领域层”这个领域层由领域专家主导。

我把这个领域层看作是一个“适配器”层。向上满足问题域，向下由具体技术支撑。 

DDD有分层模式，也即：可以分成业务领域和技术领域，各有各的上下文、通用语言、上下文章映射等等吧。所以它们也不冲突。

以上是我的粗浅理解，欢迎任何观点。