领域驱动设计-笔记

本文整理自《DDD quickly》中文版，你可以在这里下载到免费的PDF版本。

简介

兴趣驱动：

我要在这个项目中使用苹果公司新推出的 Swift 编程语言，在服务器端要使用Hadoop，最好再尝试一下深度学习方面的技术”

人月神话：强调软件开发的概念完整性。DDD（领域驱动设计）是维护软件概念完整性的良药。

Evans：衡量一种技术好坏的最终标准，是这种技术是否有助于开发人员专注于研究领域问题。

需求的反向工程： 需求往往是从设计中反推出来的（糟糕的工作方式）

模型：对现实世界有选择性地精简。

从业务（领域）模型入手，而不是从技术层面入手。

MDD：模型驱动设计 MDA：模型驱动架构

DDD：传统OO泛型的探索和升级版

软件起源于其领域，并且与其领域密切相关，需要自动化的业务流程或者真实世界的问题，就是软件的领域。

让软件成为领域的一个映射，软件需要包含领域里最重要的核心概念和元素，并精确地实现它们之间的关系，即软件需要对领域进行建模。

用模型来交流。

领域抽象（领域理解）：以空中飞行监控为例

演化：

与领域专家（空中交通控制人员）继续深入交流，反馈：

从领域的基本概念中，提炼出模型，模型作为软件开发人员与业务人员的交流工具-> 基于模型的语言，通用语言。

---

通用语言

出发地、目的地、路线、飞行计划、海拔高度、巡航高度、巡航速度、飞机类型。
模型继续演化：

沟通方式： 图、UML、文档

---

模型驱动设计

如何完成从模型到代码的转化。

分析模型：业务领域分析的结果，不需要考虑代码如何实现。–>模型与软件设计不匹配。

将领域模型与设计紧密关联起来，开发人员加入到建模过程。

模型驱动设计的基本构成要素

分层架构（layered architecture）

将领域与其他软件部分分离：