概述
《领域驱动设计》软件核心复杂性应对之道。读完之后几个感受：
- 架构设计的从混乱到模式和方法论，后面会说
- 复杂问题依然还有“具体问题具体分析”的感觉，很能理解方法论是不是严格的数据公式，还是有需要“看手感”的地方。但是书中大致给到了思考方向
- 借鉴经典现有的领域模式是一个值得推荐的方式
- 文中大量引用《分析模式》一书，有时间可以接着读这本
- 一句话概括领域建模的核心：找到真实世界到计算机世界的映射，从三个维度来映射，事物-->对象，行为-->方法，关系-->协议（部分教材可能还有 职责 --> 职责的映射）
通用原则
- 低耦合和高内聚，是通用设计原则。
- “查询修改”分离，也可以认为是一个默认规则
书中提炼出的一个领域建模方法步骤
-
1 简化需求描述，【提炼“术语表”】
* 通用语言表，便于沟通，语言词汇对应类名，重构要同步修改
* 领域专家有自己的术语，技术团队使用的语言经过调整，便于从设计角度讨论领域，讲话和写东西使用的语言不一致，削弱了知识的消化。
* 解决2: 创建通用词汇：类和主要操作名称，通用词汇的更改，就是对于类的更改。【沟通的时候，直接用类名作为词汇来沟通】。
举例：RoutingService查找满足RouteSpecification的Itinerary。
做到图，模型，代码（类）的统一。 -
2 分层设计，目的：拆分出领域层
* 一种分层示范：
- 用户界面层
- 应用层（跟踪查询，事件日志，预定应用等等，领域对象的调度，任务状态）
- 领域层（业务状态和业务规则，技术细节可以由基础设施层提供，这一层是业务软件的核心。用户，物品，事物行为规范，使用记录，地点，Event等）
- 基础设施层（为应用层传递消息，为领域层提供持久化repository，为用户层提供组件）- 在每一层内分别设计，使其具有内聚性，且只依赖它的下层（>>>单方向的依赖）只与上层进行松散耦合，下层调用上层，可以用回调或者observers模式。
-
3 领域层中的设计：
-
拆分core domain，一般用一段话精简描述(考验产品经理)
``` 比如： 航班预定系统，模型可以表示乘客优先级和预定策略， 乘客模型反映出回头客关系， 所以需要乘客的历史记录，参与过的活动以及人员关系。 模型支持航线，座位搜索， 集成到航空预定系统中 ``` -
领域内部可以继续分层，上面的层知道下面的层做什么，但是下面的层不知道上面的层
-
领域中的分层参考：
决策层（制定决策）-->策略层（决策依据）-->承诺层（对于用户特殊承诺）-->作业层（行为）-->能力层（能做什么）
-
-
4 领域对象，模型和关联
- 表示模型的元素：module，service，entity，value object
（网上的教程也有其他叫法：实体，服务，值对象） - 生命周期：Factory开始，repository结束
- 注意：dal（数据库映射层，简单一点模型通常和 领域层是一样的结构。早期的J2EE应用一个领域对象对应一个bean，但是这个方式影响开发效率和程序效率），复杂一点的领域是对象数据 + 行为方法
- entity中注意id的设计
- 系统如果比较大，模型提炼出module，提高内聚
- 不同模型需要明确职责边界，避免多个系统修改同一个模型，增加有歧义属性
- 职责不同的两个context，可以有自己的术语表（方言表，然后建立概念转化映射），就是对象到对象的转化，
- 梳理aggregate边界
- 设计领域中的【关联】，定义查询的方向， 注意为了简化关联查询，可以在entity中加入冗余字段
- 优化关联方式：1 指定关联方向，把多对多简化为一对多（ps：感觉有时候需求要求多对多，难以简化）
- 优化关联方式：2 添加限定符，减少不必要关联
- 表示模型的元素：module，service，entity，value object
-
5 场景走查，
模拟几种功能使用场景，推演系统的可行性
比如：- 一个业务流程：下单
- 复制：prototype模式，复制一个aggregate，比如根据历史订单再创建一条
领域建模的其他工具和方法
- 1 事件风暴
- 2 找到聚合根
以银行转账的例子:
账号（Account）是以下两部分的聚合根:
- 客户信息（CustomerInfo）Entity
- 值对象（Address）
其他提升设计能力方法
- 1 扩充领域知识，可以借助书本
- 2 咨询领域专家
- 3 现有模型和架构设计学习
- 4 图是一种沟通手段，简洁的小图更好的实现沟通目标。
另一种设计方式：Smart UI
smart ui完全违反领域设计原则，用户界面中实现所有逻辑，分别绑定用户界面和业务逻辑，实现可视化编程，处理的数据通过数据库共享。这个模式自有其好处，但是和领域设计原则不同。
网友评论