领域模型设计
领域驱动与微服务实践
领域模型设计
领域 -> 模型（充血模型） -> 数据库设计
- 事件风暴法
- 原文分析法
- 四色建模法
数据库设计
继承关系的处理（NoSQL or sssssRDS）
程序设计
服务（Service）
领域建模中标识某些行为或操作 ——- 一组实体操作的组合，组成服务的行为
实体（Entity）
领域建模中表示每一个业务个体的领域对象 —— 模拟现实世界的物体，有属性和操作
值对象（Value Object）
领域建模中表示某个客观事物的领域对象
贫血模型设计
service层同时包含业务和技术实现，随着业务的发展代码会变的不易维护
充血模型设计
service层只聚集于业务，把技术实现细节封装起来，通过领域对象把业务和技术实现隔离开
聚合关系
工厂（Factory）和仓库（Repository）
限界上下文 - 可以用来划分微服务
领域驱动设计的分层架构
微服务应该小而专， 数据库表只由一个微服务维护，其他微服务通过接口调用对应的微服务来操作该表
去中心化数据管理
MySQL、TiDB NewSQL（生产库）、NoSQL 大数据分析平台（查询库）
微信服务架构实现读写分离
实时（秒级）查询方案： 事件 + NoSQL （大宽表）
数据库纵向拆分
减少join
生产库，查询库
跨库关联查询解决方案
方案一：分步查询，数据补填
存在问题 会有一些条件不好过滤， 可以使用数据字段冗余来处理，但是也有局限，只适合相对固定的过滤条件
方案二
NoSQL空间换时间，写到一张宽表里，相当于提前join后写入NoSQL，查询的时间从NoSQL里查询
领域驱动与微服务实践
为什么需要领域驱动
在新项目开发中起作用吗？
在老项目维护中起作用吗？
在技术架构演化中起作用吗？
业务越复杂，领域驱动越有用
新项目开发时用领域驱动主要是着眼于日后维护
新项目为了快速上线，没有使用领域驱动，后期如何转换成领域驱动设计？
采用领域驱动设计思想对原有业务分析，领域事件
领域模型主要解决增删改
对于新业务需求需要站在整体全局视角思考
形成战略规划（子系统、限界上下文、功能模块）
先做用例模型设计，再做领域模型设计
限界上下分怎么划分？
- 业务相关性，相关性强的放一起
- 业务的复杂性或者规模，单个限界上下文应该相对简单，小而专，符合单一职责原则
- 支撑域，公用的信息
用例模型
第0层：子系统划分
第1层：针对子系统细化，描述每个用例
操作用例关注的是事件流，如果单个事件流很复杂可以再拆分成多个子用例
查询报表用例、图表展示用例关注的是数据内容
第2层：界面原型
领域模型
在需求讨论中建模
原文分析法 分析用例描述中的名词（对象、属性），动词（后端动作）
若是复杂概念名词则对象，若简单的一个则为属性