技术上我们经常强调模块化、组件化，但是能真正实现软件模块化，需要通过对业务领域有一定程度的理解才能达到。
我们可能有专业培训组件和模块技术的课程（OSGi等），但这类课程并不会告诉我们所在的领域上具体情况应该如何划分模块，大概辨别和划分模块的能力是理所当然。但事实上并非如此。
用一个例子说明：假如一个网站需要添加一个广告功能。大概有以下可能性：
最后两点的关键在［属于］如何界定。
新的广告功能［属于］内容管理（CMS）的一部分吗？毕竟广告也会有内容的特性（有文字，图片，超链接等等）。
广告功能也可以自成一个模块，因为广告的点击率直接影响网站收益，跟网站内容的点击性质不一样，处理的结果也可能不一样。
另外有可能广告功能是市场部管辖的范围，广告的效果经过分析后可能会到业务部和财务部做核算。从业务流我们也可以认为这个广告功能属于市场部的一个系统功能。
在Eric Evans的Domain Driven Design提倡领域设计的重要性，当中Bounded Context提到模型边界问题。而Sam Newman在Building Microservices书中也提到微服务最好也依据Bounded Context来划分。
通常我会依据以下关系来做模块划分：
另外有两个重要的技术概念也需要参与分析：低耦合性，高一致性
低耦合 ＝ 改变一个模块的代码，不导致需要修改依赖这模块的其他模块的代码高一致性 ＝ 同一个领域的对象，尽可能放在一起并一起发布
还有一个简单的检查，就是通过换位思考，，站在一个领域的角度上，判断这个领域词汇应该在什么模块出现、和不应该在什么模块出现。
喜欢就该珍惜，珍惜就别放弃。
