个人对架构上分层分域的理解

本文的起源是本人实际工作中参与讨论并实施的一次架构改造，下面结合本人的实际工作谈谈对架构上分层分域的理解。本人所在的team主要是负责资产二级市场的交易，主要有资产的转让，回购，质押，在进行改造之前，我们的架构大致是这样的：

我们所面临的问题:

1，前期为了快速上线，一级市场业务和二级市场业务全部揉在同一个p2p-app中，代码也交错在一起，有些数据表也是共用的，随着业务的发展，弊端就出现了，不利于维护。经常出现的一个情况是一级市场稍微改动下代码，就可能将二级市场的业务逻辑改坏了。

2，前期为了快速上线，p2p-web也是一二级市场共用，那时移动端的流量还比较少，所以mapp-web整合了所有业务线的移动端入口和出口，简直是一个大杂烩，它需要接各条业务线，后面业务发展越来越快，时间一长，或者老员工离职未交接好，后面的人不了解各个业务线逻辑的话根本不敢有任何改动，随着新需求的加入，并且重心都往移动端倾斜时，mapp-web已经越来越臃肿，很难维护。

3，由于历史原因，我们的系统还存在下面的问题:

p2p-web对p2p-app 和A-app都有依赖，而p2p-app 和 A-app又相互依赖，相互之间有扯不清的关系，举个例子，A-app有需求改动时，这个改动变得不可控了，可能需要找p2p-web问下是否有影响，同时还需要去找p2p-app问下是否有影响。

4，存在这样的问题，不同业务线之间的数据库数据表，随意相互访问，sql质量不可控，可能因为非核心业务线写了个质量超差的sql导致核心业务线无法正常访问数据库。

5，大量的db耦合，典型的通过join其他业务表来实现自己的业务逻辑，随着业务的膨胀，数据量越来越大，可能需要一个大库来容纳超级多的业务表了。

1，为什么要进行分域？

由上面的场景我们可以知道，问题的根本在于各个应用(业务)间的界限没有划分清楚，这应该是大多数创业公司的通病，在初期，项目为了尽快上线，怎么简单怎么来，随着后面需求一步步的叠加，发展到现在的地步，问题就一步步地凸显出来了。所以我们进行分域其实就是彻底划分清楚各个业务直接的界限，这样有什么好处呢？

a，业务界限清晰，业务间的相互影响降到了最低，比如上面的问题一，分域后一级市场和二级市场各自相对独立，不用担心改代码的时候不小心把对方的业务逻辑给改了。这样业务线各自有大大的自由改造发挥空间。

b，业务界限清楚后，原来直接写sql访问数据库的改为rpc调用接口获取数据，这既可以解决db耦合也可以控制sql质量

2，为什么要进行分层？

随着时间的推移，产品为了追求更加绚丽的效果，对不同的设备展示上有不通过的要求。同时因为前后端分离，我们的前端只管页面的布局和数据的渲染，后端将要展示的数据直接吐给前端。为了应对不同设备上的需求，后端可能对返回的数据进行必要的裁剪、修饰等，这样一个典型的问题是首先大多数的展示数据是共有的，其次是不同设备的个性展示数据，后端可能针对这种个性化的数据，进行了各种if else的判断，然后拼接，处理等等。这样有可能在改pc端的展示需求时，把app端的代码给改坏了。针对这种情况，我们可以抽取出一层专门处理这种情况，同时再有一层专门做数据整合(各种展示的全集),经过分层分域后我们的系统大致如下图所示：

1，在web服务器层，我们从原来的p2p-web中拆出来一个属于自己的secmkt-web，它主要用于pc端的接入，同时从mapp-web中拆分出m-secmkt-web，负责移动端的接入

2，数据整合层，为什么会引入这一层呢？一是由于前端展示逻辑多样，既可能调用本域的app获取数据，也可能需要访问其他域的app获取需要的数据，所以需要这个整合层。二是这层引入后，基本上可以解决掉我们上面所说的相互依赖问题。这一层只做数据的整合，不含有实际的业务逻辑。

3，app应用层，这层用来专门处理业务逻辑,

4，svc层，该层只提供数据库的访问，为什么会有这一层存在呢？应为我们发现，在实际业务中，有其他域的app层需要访问我们的数据库，根据我们的规则，app层只能访问比它更下层的应用，所以有了这层

5，db和缓存

通过以上的分层和分域，我们的系统脉络变得更加清晰可控。虽然有上面分层概念与规则存在，但是在实际实施过程中，我们还是遇到了一些挑战我们规则的问题：

1，域之间的app应用层需要进行访问，比如A-app有些复杂的逻辑需要B-app（另一个域）来协助进行处理，这就免不了相互访问。但根据我们的原则，上层应用只能访问比它更下层的应用，意思就是A-app不应该直接访问B-app，因为它们都处在同一层，这个问题如何解决？

针对这个问题，我们采用的是mq发送消息的方式A-app处理完后，发送mq消息给B，由B进行消费，消费结束后，再发送消息告诉A已处理完成。