如何合理的进行模块划分
模块设计上的思考
10月27日晚上，我们四个人开了第二次的会议。第一次会议上，我们讨论了我们的原型设计，并做了很多的细节明确和完善。这一次的会议，我们原计划是进行模块划分、restfulAPI设计，以及数据库结构设计的。 But！ 我们愣是在模块划分上就卡掉了两个小时……QAQ
第一阶段：瞎想
我们先按照刘老师的建议，按页面和功能进行划分，我们根据我们的页面把功能点一个一个的列举了出来，得到了这么一个东西
然后我们发现了一个问题，如果我们按照这张图来分包的话，项目的耦合度还有模块的复用性差不多就不能看了，写出来的肯定是一团垃圾。而且，从这张图开始走的话，是从使用者视角去思考，而不是从开发者和程序的角度出发的。
第二阶段：转变思考方向
所以在第二阶段里，我们从程序开发的角度出发，思考了我们的项目需要哪些东西，我们整理出了顶层的三个模块：数据提取模块，通信模块以及排队任务调度模块。
是的，然后问题又来了。
- 第一，这三个模块是不是已经足以涵盖项目的内容了，有没有遗漏？
- 第二，这三个顶层模块的结构是怎么样的？是平级的，还是结构化的？
- 第三，这个划分方式对么。。。。。
我们起先对自己的系统的整体结构设计大概是长这个样子的：
那么在这里面，我们的通讯模块在哪？我们的任务队列又在哪呢？我们觉得通讯和队列管理可能都是在中间件层。即使如此，这个模块的粒度也太大了，也不便于我们接下来的API设计，也不能与功能点相互结合。
然后我们就算彻底宕机了……
第三阶段：向工业界巨佬请教
我把我们的聊天记录和项目文件等等整合了一下发给了奇舞团的月影大大，然后月影大大指出了我们的问题：
业务模块划分应该是针对需求功能点的，而系统设计是二维的，横向是需求功能点，纵向才是系统服务级别的分层，感觉你把这两者弄混了
从非业务的功能上来讲，一个典型的web架构是分层的。不论是koa也好、fastify也好，解决的都是基础的web架构上层的东西，也就是路由、拦截器、http请求和资源加载。但是这只是纵向的一层，而且这里不论koa也好、fastify也好并没有解决业务模块的划分，也就是横向的子系统和接口划分的问题。对于它们这样的web框架，其实对应于php或者python-http本身。但是php和python在这基础上还有其他的专注于业务的MVC框架，比如PHP的laravel或者python的Django，它们解决的问题对应在我上面那张图里面的 Controllers、Model 和 View。ThinkJS 也是同样的定位。它底层基于koa但是抽象出MVC各层。其实业务模块划分是在 controller 上的。比如管理员模块、客服模块、首页和其他模块。然后其中又分为比如权限子系统、问题反馈子系统、客服专员信息管理子系统等等。其中有restful接口、websockets接口、或者其他比如页面模板之类，具体逻辑都实现在controller之上。其下层是model，model底下是data adapter，再底层是具体的DB或者其他持久化服务，这部分是和业务无关的。controller之前是路由拦截器，将指定的请求分配个不同的controller的特定action，根据不同的url、verbs和不同的协议，一般用url对应不同的业务api。比如说 http://dc.360.cn/admin/user/add?params...， 对应 admin 子系统、user controller、add 操作，params 是参数。再比如ws://dc.360.cn/user_messages/connect/[id] ，对应实时用户消息、建立websockets连接、对应用户id，通过设计url来划分业务需求，路由负责将url指定分配到对应的controller。fastify 里面实际上有实现路由，但是只是实现了最简单的路径匹配。总的来说就是把业务模块和功能模块分开，系统功能模块和业务模块是没有直接关系的。
总结
总结起来，模块划分需要注意以下几个问题：
- 从开发者的视角去考量你的系统，而不是使用者
- 明确什么是系统设计，什么是业务模块划分，不要将二者混为一谈
- 熟悉成型的设计框架，借助MVC，MVVM等成型的设计框架，能更好地规范你的思路，帮助你发现你的项目应该是怎么真正组织起来的
- 理解高内聚低耦合到底是什么而不是只会喊口号
相关评论