前言
大家好，我是小郭，前面的一段时间学习了架构设计的基础以及架构设计的实践，今天是我们最后一个环节划分模块。
之前，我们在开发的时候总是惯性思维的以某张业务表的维度进行三层结构的功能开发，没有去思考他们功能模块间的关系，只是为了完成目标而进行开发。
接下来，主要以功能模块的划分、分层划分、用例驱动模式划分来学习划分模块。
书籍
软件架构设计-程序员向架构师转型
功能模块划分
认识什么是功能树？
说到功能树，需要先确定他的来源避免方向错误，通常情况下是根据上游的客户或者产品经理提出的，我们根据他们提供的需求文档、市场材料、方案书来确定整体要的是什么东西。
他的作用是呈现问题领域，将功能组和功能项的关系呈现出来，从而进行需求层面的分析
给我们带来什么价值呢，主要就是覆盖全部功能点，避免遗漏。
划分功能模块图
根据功能树对系统模块进行划分，通常是将涉及相同的函数、字段将这些功能映射到同一个功能模块
这一步是有架构师来实现，为客户呈现解决方案，提炼业务中的共通点，目的是为了达到高内聚，低耦合。
可以看的出来功能树和划分模块图两个是相辅相成的，利用功能树确认功能点的完善，将功能树中高度相似或者相同的元素点整合出来，划分模块。
分层划分
很多人做开发的时候，不知道为什么需要分层，只知道别人也是这么分的，我也要分。导致根本不知道每个分层之间是有什么区别，可能就出现了在Controller写一大堆业务逻辑的场面。因此，学习还是要知其然知其所以然的。
常见模式
上面的两个方案就是我们熟悉的MVC架构，每一层都有他的含义，在展现层我们只需要关心接口的出参入参是否合规，在业务层我们只要关心业务的流转以及异常的处理，在数据层我们只需要关心怎么去数据库查询数据。
他们的优点：
- 一定程度的关注点分离
- 规范了层间的调用关系，降低层之间的依赖
实践技巧
设计分层结构，从上下文图开始，这里在提一嘴上下文图是什么，主要就是顶层数据流图和黑盒的用例图
那从上下文图，获取需求分析，来确定外部的用户、确定数据库或文件持久化设施、确定第三方系统、确定定时任务的触发。
完成了第一步需求分析确定，再来确定我们的分层结构。
用例驱动模式划分
本质思想：从点到线最后到面
什么是点呢？我们的用例就是点。
什么是线呢？众多用例汇聚起来的，组成一个类就是我们的面。
什么是面呢？就是划分的模块。
我们从两方面入手，需求层与设计层
需求层：
- 用例图定义系统能提供给外部Actor的功能
2. 利用用例规约，进行进一步的确认
设计层： 打破黑盒，识别一个用例背后的类，以及设计类之间的关系
- 运用鲁棒图，发现实现用例需要用到哪些类
- 运用序列图，明确类之间的关系，更重要的是通过序列图来思考边界问题
通过多个实例识别出这些类，将他们划分到不同模块
- 运用包图
