模块设计首先要对模块的划分明确，哪一部分是做在哪个模块的，要十分清楚，要明白多个模块间的边界在哪里。
如果别人仅仅告诉我这么一句，然后我也没有实际这样去做过，仅仅是听说，那么无疑，上面的一句话可能并没有什么用，但其实，真实的做完之后，关键的点，也就如上面所说。
要对模块划分清楚，首先就要对业务有足够的了解。
如果要做一个架构师（偏业务），架构的经验来自于哪里呢？业务！理解业务是最核心的，如果不理解业务，而只考虑技术上怎么按照产品所说去实现，无疑是一个失败的架构师，做出来的东西，有可能是不具备弹性的。
如果自己对业务都不熟悉，那么做出来的东西，即使在开始满足了产品需求，但因为对业务的核心内核缺乏了解，就是依葫芦画瓢，不得要领，做出来的东西就像用火柴简单拼凑一般，风一吹，或轻微的震动，都有可能导致整体的结构崩塌。
所以需要有一个稳固的核心，就拿汽车来讲，它其实可以细分为很多部分，发动机、轮胎、油缸、方向盘等等，很多部分都已经实现了模块化，是按照市场标准来的，即使要对汽车做一些改动（符合规定），也不会导致所有的配件都改变。这样一种设计模式，即使汽车在某个地方损坏了，也只要修那一部分就可以，而不是从头到尾全修一遍。
像汽车这样的设计，就需要对它的“业务”十分精通，也就是对汽车的结构了然于胸才能做到。
软件的设计也有异曲同工之处，“业务”模块可以想象成单独的“领域”。
这个“领域”并不是完全四通八达的，到处都是门，从哪里都可以进来，从哪里都可以出去，谁都能进来做事，具体做啥事也没啥限制，到时候出了什么事连个人也找不到，可以说是“治安”非常差了。即便是在乱世，很多城池也会有城门的守卫，就是为了确保基本的治安问题。
模块的设计同理，得有统一的“门”，也就是接口，进来的人都要核实过身份，就拿《凡人修仙传》来说，在天星城居住需要有居住证，这个是进入天星城的一种身份标识。想到这里，就不得不提下居住证，或学生证，什么一网通办等等类的，都是具有在某个地方通行的功能，如果要去更特别的地方，就需要更特别的证或卡，这在一定程度上，做了身份的识别，并且起到了一定的维护稳定的作用。
如果去哪里都需要重新获取一个新的身份，肯定会比较麻烦，所以有统一的身份证，但即使这样，身份证也只是在国家层面的。如果去了他国，身份证就不一定适用了，这就需要在进入他国之前将身份证与一个物件进行转换——护照。从这里看，也能看到一点模块思维的影子，在人进入他国前，先调用“接口”进行身份转换，获取到了在他国（模块）中的护照（通行证），这样就避免了要把身份证全球通用的难点。
如果某一个东西是通用的，可能意味着使用这个东西的范围还不够大。县级适用的想想跨县问题，市级通用的想想跨市问题…直到跨国问题，地球以外的星球问题，甚至世界的维度问题。
现代科学是在一定的数理化等学科基础上的，例如早期的牛顿三大定律，爱因斯坦的相对论，量子力学等。每一次新的发现都会掀起新的技术变革，可见“通用性”的影响之大。
这种“通用性”对于软件的模块设计来说，意义可能是相反的，并不是说在其他地方能用的东西，在这个模块也能用。恰恰相反，因为模块的设计就是要尽力屏蔽外部影响，目标是构建稳定的与其他模块无关的领域，它是理想化的，自洽的。以这个角度来说，模块设计是“反通用的”，它追求的是内部的自洽。它的“通用性”可能更像“适应性”，无论这个模块被集成到哪个项目中去使用，它需要做的变动是极小的，也就是适应性比较强。
总体来说，模块设计，需要对业务有充分的了解，分清楚业务的边界，并尽量降低外部对它的影响，这样的设计是为了更好的复用，可扩展性更强，而且可以降低不同模块间人员协作的成本。