近年来微服务/SOA很是流行，我们团队赶时髦，也玩了玩。虽然用的时间还不长，但也已经踩过不少坑。今天想记录下自己对边界问题的一些思考。

很多人在谈起微服务时，总是会很自豪的说，微服务为我们提供了高内聚低耦合的明显好处，因为微服务强化了模块化的概念。但是， 如何模块化，如何明确的定义模块的边界，却很少有人提及，而这正是微服务架构的难点，也恰恰是开发人员技术能力的体现。如何正确的定义模块的边界，似乎还没人总结出一套理论原则。

当我们将一个单体服务进行模块化拆分时，我们总是能够很轻易地找到模块边界。那些不知道该放到哪个模块里的代码，便是我们模块边界的所在。在整理这些棘手的代码时，就是一个划分边界的过程。如果实在挪不开，这说明他们本就该属于同一个模块中或者他们上层应该还有一个服务。

在实际开发过程中，对单体服务进行重构的时候并不多。更多的时候，我们一开始做服务架构时便在使用微服务的架构模式。随着系统需求的渐渐复杂化，我们会发现，服务间的耦合越来越严重，甚至出现了循环依赖。这种时候我们不得不质疑自己，当初的模块是否划分的足够清晰。

我们做了一个借贷系统。系统中有两个核心服务，借款与还款。

借款的核心需求：

A。用户可以借款；

B。用户可以查看自己的借款明细。包括借款时间/金额等。

还款的核心需求：

A。用户可以对借款进行还款；

B。用户可以查看还款明细。

一开始，一切都显得很美好。我们遵循kiss原则，让各个模块尽量简单；同时为了项目组开发的便利，我们尽量将模块细化。于是划分了一个借款模块，一个还款模块。此时，我们服务的依赖关系很清晰。还款模块会单向依赖借款模块。还款成功后，通过消息进行解耦，对借款余额进行更新。

但随着系统需求的变化，借款详情中需要展示用户当前的还款情况，并计算未来的还款计划，这些都需要依赖还款模块。这种情况下，我们便形成了双向依赖的循环。借款模块会依赖还款模块，还款模块也依赖了借款模块。

这种情况下，出于项目进度，我们并没有进行任何的处理，而是任由双向依赖的发生，甚至，在还款模块直接依赖了借款的数据库来达到快速开发的目的。但这也为日后欠了技术债。

A。循环依赖日后可能会带来循环调用，这种结构上允许的闭环调用，很有可能在将来造成无意识的递归，让系统崩溃。

B。项目构建时，A/B模块的循环依赖，造成无法构建甚至循环构建。对我们系统的持续集成造成了障碍。