整个建模过程，个人总结来说应该分为3个阶段
- 前期准备工作，了解问题领域的现状，做好目标分析
- 做好模块的划分以及具体模块的设计
- 对整个项目进行总结反思，包括目标的达成情况、设计的实现情况，设计是否存在不合理
前期准备工作
了解问题领域
了解业务概况
在这一步，我们需要了解现在业务的“概况”，强调一定是概况，现在还没到具体详细分析业务的时候。了解业务概况，主要就是了解业务的目标，动机，和主要的流程。以及业务的主要上下游和会有哪些涉众。
整理业务目标
了解概况后，我们就可以整理“本次”需要建设的业务目标，目标一定要是可以量化的值，比如“让流程从10步简化为5步”，“让操作时间节省30%”这种，而不是“让流程更加简便”，“让操作更快”。
做好涉众分析
根据业务目标认清受众
涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分。如何理解与业务系统相关的一切人和事呢？凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。
在这一步，按照书里所说，主要根据分析方法，产出涉众分析报告和用户分析报告。
需要注意，需要按照引用的说明里来区分涉众和用户，比如在一个系统建设初期，涉众包括所有流程中的参与方和相关利益方。比如我们要修一条铁路，那么从铁路局，到建筑局，到建筑工人，到需要拆迁的那些人，其中的涉众无比之广，我们在准备工作时就需要尽可能考虑这些涉众对这件事不同的需求，来避免后续无意义的纠纷或者纠正。
举例而言，对于一个登录功能而言：
涉众分析报告
| 编号 | 涉众名称 | 涉众描述 | 期望 |
| 001 | 老板| 公司老板 | 尽可能省钱 |
| 002 | 项目经理| 项目经理 | 不要延期 |
| 003 | 年轻用户 | 55岁以下的用户 | 界面漂亮 |
| 004 | 老年用户| 55岁及以上的用户 | 操作简单易用|
| 005 | 安全负责人 | 安全工程师 | 系统符合等保标准，无隐私和泄露风险 |
| 006 | …… | …… | …… |
我们可以看到，涉众包括了这个系统影响到的各式各样的人，从甲方到乙方到实施方等，在分析涉众的需求的时候都需要将他们的诉求尽可能的罗列出来，在实际实施和后续操作时，再按照优先级以及系统愿景综合做取舍。按照阿布思考法来说，我们这一步需要在给定时间内尽可能的考虑涉众的期望，但不能因为涉众过多，过广，期望五花八门或者无法想象，而放弃这一环节。
用户分析报告
用户分析报告与涉众分析报告相同，甚至可能只是其中的一部分，因为用户是涉众的一部分，只是其中的子集，这里就不再赘述了。
系统或者业务模块的划分以及模块的设计
笔者因为是做后端技术的，所以这部分的思考以及篇幅会更多一些
两种划分模块的方式
模块划分一般有2种方式，也就是目前诞生的大多数架构设计背后的划分方式
按照流程（过程）划分
这是大多数人思考问题的方式方法所带来最基本的划分，划分的手段是根据系统提供的用例以及能力进行最底层的区分，其他的上层合并聚合也是一些底层过程的聚合，比如：注册+登录+忘记密码=登录模块
这种划分一般有以下几个特点：
- 根据业务流程来，整个设计以及边界都依据业务操作以及业务流程
- 每个模块，往往是从业务流程本身直接穿透到对应表模型，核心目的只是为了完成操作
- 很少复用，因为复用在这种划分模式里会带来更多的问题，复用反而在这种划分是不应该被推荐的
举个例子，我们一些大多数系统，其实都是按照这种思路去设计的，或者说，大部分没有进行“设计”的系统，都是依循的这种方式。
最常见的，我们开发一个登录流程，就从接口到用户表直接干下去，我们再开发一个注册流程，也是这样，再来个忘记密码，也是如此。
优点：
- 耦合低，单流程开发中，只需要专注于自己流程所涉及到的表以及状态关系表示
- 思考和抽象成本低，力大砖飞
缺点：
- 会出现很多重复代码或者重复工作，令一些人忍不住去复用，带来更多的问题
- 当依赖同一个表或者同几张表的流程过多时，这种复用反而也难以避免，导致这种因为表而导致的影响很难被评估
- 往往自己的流程有时对其他的流程会产生入侵，此时会因为对他人流程不熟悉，改出更多的问题（比如新增登录日志的管理台查看功能，就一定会对登录流程产生入侵，因为要在登录时进行埋点
{{< admonition type=note title="复用不一定是好事" >}}
复用也会带来依赖的耦合，被复用的越多，修改时影响的也就越多
当某次修改需要对复用的逻辑进行修改时，此时抽出复用方法放弃复用或者修改复用方法达到特殊目的，都不是一个好选择
如果一开始就没有选择抽象和聚合，后续仅仅从相同这个目标出发来复用方法，不是一个推荐的做法
{{< /admonition >}}
按照业务对象划分
这是目前一些流行的高大上的架构设计的背后逻辑，比如中台、领域驱动
这种设计的出发点是业务系统中的业务对象，从业务对象所具备的能力来进行设计
优点：
- 有了所谓边界的概念，因此跨流程之间的修改风险很低
- 在已经业务很清晰的领域，可以大大降低开发成本
缺点：
- 思考和抽象成本高，一般都是对已经成熟的系统重构，或者对业务已经很清晰的领域，才会使用
- 缺少明确的标准和落地方案，实际上是以架构个人理解以及想法去落实和实现的，理解成本反而更高