进行模块划分

业务逻辑入手

1. handler层 部分业务逻辑下沉到微服务-沉淀为领域service
2. handler层 部分业务逻辑整合到应用服务模块

Mapper

1. Mapper 已使用tkmybatis

Model

1. model 新增自身逻辑（校验、等），划分到 领域model
2. model 北向 ， 面向数据库
3. message 南向 ，面向业务层

领域发现

那领域模型是怎么一步一步确定下来的呢？推荐两种比较常用的领域发现方法：事件风暴与四色建模法。

一、事件风暴

Event Storming（事件风暴）是一种轻量级的系统分析方法，基于 DDD 的概念，能够为我们梳理系统中的各种相关元素，其中包括了核心的 Aggregate。它能够帮助开发人员梳理核心的业务对象，从某种程度上来说就是就是领域对象中的聚合。

描述产品愿景

产品愿景的主要目的是对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。

产品愿景的参与角色：领域专家、业务需求方、产品经理、项目经理和开发经理。

事件风暴关注点

事件：某个动作的结果

属性：事件的输入、输出

命令：某个动作

实体：命令的触发者

简单理解就是谁（实体）使用什么（输入）做了什么（命令、动作）产生了什么（输出）影响了什么（事件）。

二、四色建模法

通过还原业务逻辑事件，依据是否影响公司的运营和发展，确定凭证作为时标型对象，并补全相关描述的建模方法。四色建模法一般运用于问题分析建模。

四色建模是哪四色？它包括——

时标型（Moment-Interval）对象：具有可追溯性的记录运营或管理数据的时刻或时段对象，用粉红色表示；

PPT（Party/Place/Thing）对象：代表参与到流程中的参与方/地点/物，用绿色表示；

角色（Role）对象：在时标型对象与 PPT 对象（通常是参与方）之间参与的角色，用黄色表示；

描述（Description）对象：对 PPT 对象的一种补充描述，用蓝色表示。

分析的五个步骤

1. 找到溯源事件
2. 确定时标型对象
3. 找到周围的PPT对象
4. 找到角色
5. 补全描述对象

四色建模法案例：

跨库关联查询解决方案

方案一：数据冗余

这是最简单常用的一种解决方案——以空间换时间，把需要关联查询的条件冗余存储在需要查询的库。

举个例子，商品与商品类目被拆到两个独立的服务与数据库中，两者通过类目编码关联，产品想通过类目名称对商品分页查询，这时我们可以把类目名称冗余到商品表存储，给它加个数据库索引即可。

做宽表

方案二：数据补填

结合Wrapper设计模式，一般在Dao层实现数据聚合——本地库分页查询完数据后，通过查询条件判断是否需要填充关联数据，若需要则通过跨服务查询相关联的服务，再对各个服务的数据进行填充组装，最后返回。