各种DD驱动设计

1. DDD 领域驱动设计

首先是支撑微服务设计思想的DDD，这套理论讲述了如何划分微服务的子系统。

1. 识别domain，领域模型
2. 识别业务边界
3. 画出UML图，结合领域专家共同进行领域建模，随着时间演进 领域驱动设计的实质：消化知识 建立领域模型

Tip 业务规则单独抽一层出来 利用策略模式 使业务规则更好阅读

我段说的好～微服务架构是一种架构的设计模式，而DDD为微服务的实现提供了理论基础，如何划分微服务系统就是如何识别 core domain和bound context的界定。DDD的设计需要领域专家+开发 一起 提炼领域模型。 领域规定后，将 core domain里的 子对象的操作都归拢到领域类中操作。 书中大量提到了设计模式中的工厂模式，场景：类本身生成规则复杂，则可使用工厂模式或建造者模式 将类的生成抽出，封闭操作

关键术语

Aggregate 聚合 ，聚合就是一组相关对象的集合，我们把聚合作为数据修改的单元。外部对象职能饮用聚合中的一个成员，我们把它称为根。在聚合的边界之内应用一组一致的规则。

**Bound context **。 限界上下文 特定模型的限定应用

core domain 核心领域，用户核心目标 是应用程序与众不同 且有价值

**model driven design **模型驱动设计，其实我们的VO、POJO早已运用了这个设计

respository （存储库） 一种把存储、检索和搜索行为封装起来的机制，类似于一个对象集合，其实也就是对应DAO层的返回的数据集， jfinal里的model更加贴近这个思想，他将实体和dao融在了一起

Layered architecture 分层架构=》mvc

• 用户界面层
• 应用层
• 领域层 业务逻辑的设计和实现组成，sevice 层和dao层再抽一个领域规则，将service层作为单纯接口使用
• 基础设施层

from 领域驱动设计：软件核心复杂性对应之道

2.ADD 属性驱动设计

~尚待补充

3.TDD 测试驱动开发

讲真，测试驱动开发一开始看有点不可思议，其实他描述的是以测试用例来驱动开发，先描述好功能测试的结果，以测试用例结果为导向进行开发，也就是说测试覆盖率要很高。--之后看了书再补充把～

转载于:https://my.oschina.net/xlpapapa/blog/3101095