高内聚、低耦合” ---- 软件模块划分的目的


软件模块划分应基于什么原则进行呢？ 
  基于功能划分、基于层次划分、基于专业划分、基于需求划分？


当前常见的划分方式为基于专业领域的划分，如：用户操作GUI，数据处理、网络接口等专业领域划分。按专业领域划分确实可以解决很多实现上的问题，这里指的是功能上的实现。


实现了在同一模块中不允许存在两个不同专业领域的内容的要求
更有利于模块的实现


有了该划分是否就足够了呢？多年的项目经验告诉我这的确还不够。


模块划分清楚后各个模块能够实现它的功能，但我们要的是一个完整的产品，是一个多模块的有机结合，但只是将多模块堆积在一起往往!=产品。为什么会这样呢？


这里显然存在某些问题
缺少需求设计、缺少需求实现、缺少了需求管理。有需求提出、需求验收，但缺少一系列的中间环节，这显然就存在问题。


需求设计
    回顾你的软件架构，在架构文档里能清楚看到模块描述，但也能看到客户的需求么？
需求实现
    当你在实现软件时，考虑了模块功能如何实现，但也考虑的客户需求如何实现么？
需求管理
    项目过程中我们在跟踪某个模块的实现，但有跟踪客户需求的实现么？


架构上缺少客户需求的设计、客户需求的划分，自然会缺少客户需求的实现、也缺少客户需求的管理。


因此软件模块的划分
    实现上需要基于专业领域的划分
    管理上需要基于客户需求的划分