MailProxy案例：粗粒度功能模块划分的优缺点

按照[[粗粒度功能模块划分的两个维度]]的思路，MailProxy邮件代发系统被划分成了一套粗粒度功能模块结构。这套设计有两点明显优点：一是立足用户需求展开思维，不容易遗漏功能——一个典型表现是，哪怕设计得比较糟糕、程序员也在抱怨架构，但系统的功能基本上都能提供，这是很多企业研发现状的真实写照；二是便于按业务功能分工，分工后的不同程序小组也容易独立工作。但这套纯粹依赖”功能组→功能模块”映射的设计也有明显缺点：设计不到位，功能模块（也就是子系统）划分得太粗粒度，缺乏对模块之间交互关系的定义。这个粒度问题会连锁引发一系列后果——因为缺乏交互关系定义，不利于模块复用（一个功能理应由不同模块协作完成才利于复用，但粗粒度划分往往把该协作的部分也塞进了同一个大模块内部）；因为不利于复用，各小组之间容易出现重复代码；更严重的是，这种划分方式无益于发现和控制技术风险——比如”要和外部哪些系统交互、如何交互”这类问题完全没有被考虑和涉及，而这些重要的设计决策本不该被简单地贴上”实现细节”的标签就直接忽视掉。这个案例的教训是：单纯从功能组映射出的粗粒度模块划分，是一个”能跑起来、但架构含金量不高”的起点，真正合格的架构设计还需要在这个基础上进一步定义模块间的交互协作关系、识别和处理技术风险，而不能止步于”每个业务功能都能找到归属的模块”这一步就宣告完成。