本文主要讨论如何合理划定系统模块间的界限，以提高系统效率、优化用户体验，并确保各模块间相互独立且易于扩展的技术问题。

一般一个庞大的系统，会分成多个子系统，那这里划分的原则是什么，后面每个子系统的详细功能的划分原则又是什么？比如商品模块，要不要加入很多的营销信息，如果加了，那后面商品和营销模块的重合度会越来越高，营销模块的一些信息还要从商品模块取，系统延展和用户体验都不是特别好，所以模块之间的系统边界怎么设置，怎么把握一个度。

01 考虑用户体验

相同角色的功能，最好放在一起，不至于导致业务需要在多个系统之间来回切换，高效完成工作。补货这一块不是考虑系统边界的重点，因为即使是不同模块，也可以在前端将多个模块的信息呈现在一个界面上。

02 系统逻辑不要夹杂业务逻辑

不能因为一个新的功能，原来的系统就要大的重构，出现这种情况，一般是模块的颗粒度不够细，系统设计中夹杂了不少业务逻辑，而业务是会变的，业务一变，逻辑就可以跟着调。就好比一堆砖块，就可以建成高楼。可是如果把砖块封装成一面墙，可是不同的高楼，要的墙不一样，这个时候，就需要重构了，把这些最小的单元（墙）拆掉。

03 模块之间功能耦合低

每个模块之间，互不影响，或者影响最小化。比如前面提到的商品模块和营销模块，商品模块的最小颗粒度是商品，营销模块的最小颗粒度是营销活动。活动变更了，我的商品还是那些商品，还是不变，活动需要关联商品，直接关联就完了。这就是好的架构，如果把商品和营销杂糅在一起，商品信息调整，对应的某些营销活动的配置逻辑也要跟着调。

04 模块之间性能耦合低

如果一个模块挂了，最担心的就是把其他模块也受影响了。比如支付环节，商品营销信息没出来，就完全下不了单了，行不行，能不能和营销模块解耦，即使一个模块出问题了，其他模块还能正常跑。

05 模块直接技术可延展

从技术视角，模块直接越独立，越好延展，延展的同时，不会受到太多其他模块信息的干扰。所以模块之间的边界，技术同学也需要介入进来。