战略设计
-
现有的组织架构中没有领域专家这个角色怎么办？
- 领域专家是指项目中精通软件应用领域而不是软件开发，有着深厚的专业知识。
- 在没有领域专家的组织架构中，我们的产品经理、需求专家，以及项目中熟悉业务的同事可以担任领域专家。
-
限界上下与微服务有什么关系？
- 微服务是由松耦合的、SOA架构的限界上下文组成的体系架构
- 一个微服务至少涵盖一个界限上下文
-
通用语言该如何输出？
- 作为指导整个系统业务和设计的指南，作为软件系统设计白皮书的一部分
- 主要囊括业务标准术语以及其定义
-
划分限界上下文的常用方法有哪些？
- 事件风暴
- UML活动图/用例图
-
限界上下文的设计有什么技巧？
- 从核心的业务流程开始动手
- 拥有独立用例的业务是一种理想的模型
- 对于较小的业务流程，整个流程可以作为一个独立的限界上下文
- 复杂的业务流程，可以借助泳道图来分析业务边界
-
限界上下文设计的原则有哪些？
- 迅速迭代以更好的发现业务边界
- 业务边界需要演进
- 关注边界清晰的业务
- 避免循环依赖
-
限界上下文的输出是什么？
- 业务边界及其系统功能
- 上下文之间的映射关系
- 服务接口的定义及规范
战术设计
-
从何处着手写代码？
- 遵循分层架构的系统设计
- 从战略设计输出的服务接口开始，自上而下构建代码块
- 关注当前限界上下文的核心问题，即系统功能
- Client Request可以更好的帮助梳理构建代码块的过程
-
贫血模型与充血模型该如何选择？
- 复杂业务应该以充血模型为主
- 简单业务下，贫血模型更具有优势
-
值对象如何理解？
- 本质上是封装（以封装值为主）的极致表现，代码安全，结构清晰，减少了冗余代码
- 没有独立的生命周期，依赖于实体
- 通过封装，更贴近业务，反映业务
- 不可变，可比较
-
聚合如何设计？
- 聚合是一组有关联关系的对象的集合，数据修改保持一致性的单元
- 通过UML类图寻找关联关系
- 外部的对象，只能引用聚合中的一个成员
-
聚合设计的原则有哪些？
- 聚合应尽量小
- 仅通过ID引用其他的聚合
- 每个事务只修改一个聚合
- 使用乐观锁保持一致性
- 客户的每次请求，应该只在一个聚合实例上执行一个命令方法
-
防腐层如何设计？
- 防腐层是连接两个限界上下文的一种方式
- Facade - 不改变底层系统的模型，严格按照另一个系统的模型来设计，属于另一个系统的限界上下文
- Adapter - 不同模型间的转换
- 实现防腐层不需要对另一个系统做任何的修改
- 推荐把防腐层的实现放在基础设施层
本文将持续更新！
