开发模块化的初步理解

因为业务需求的变更，做了很多模块化处理，为了便于记忆学习，给未来的自己提个醒，特来get此刻的感悟。

场景需求：

一开始父级下面可能有好几个小模块，但是有一个小模块做的很出色，远远的超出的其他模块。为了利益

最大化，那么就有请偶们把这个模块独立出来，且不能影响其他任何模块。

需求分析：

既然独立出来，首先要考虑的域名地址也要变换，比如以前该模块地址为：xxx.test1.com/module1/index.do

那么现在就变成了xxx.test2.com/index.do；这样，也就实现了域名的独立。对于域名的独立，每个框架的处理方式

不一样。比如laravel框架的路由中可以进行简单的配置一下，意思就是当域名为xxx.test2.com时候，下面的所以路由

就走这里的，这样我们就可以从视觉上实现了模块独立了。

//模块的独立
Route::group(['domain' => 'xxx.test2.com','middleware' => [ 'api.auth']], function () {
　　//这里就是你自己的路由
});

当然如果你不想在框架配置也行，可以在服务器中进行配置，以配置Apache为例子

<VirtualHost *:80>
2         ServerName xxx.test1.com
        ServerAlias xxx.test2.com
        DocumentRoot "/var/www/html/xxx.test1.com/sites/b/"
5         <Directory "/var/www/html/xxx.test1.com/sites/b/">
6 Alias /static/ "/var/www/html/xxx.test1.com/sites/static/"
7 Alias /conquer/ "/var/www/xxx.test2.com/sites/static/"

好吧，结束上面一堆配置的废话。下面开始讨论一下，如何进行逻辑的分离。恩，既然说到逻辑上的分离，就我目前的

个人经验来看，最简单粗暴的方法，就是在数据表中，建立多个所谓冗余字段，当入库的时间，区分一下添加字段所属

的模块；读库的时候也就是多了个where判断条件即可。如下图：

当然这样做前期是方便了，满足了当前需求，当时后期你会发现会越来越乱，越来越冗余，维护起来比较麻烦。第二种方法，

就是分表。对，就是分表。所谓的分表就是，以前的查询展示数据的方法一点都不变，不要去改动它。区别就是，数据入库

的时候新建一张原来一模一样的表，然后进行入库操作到新建的这张表中。把这些数据慢慢的挪到新的数据库中。恩，暂时

就是理解这么多吧。

个人小结

无论你构思的多么好，代码写的有多么优秀，代码实际环境的运行才是检验的唯一标准。我虽然走的很慢，但我从未放弃，

前进依然在继续，不积跬步无以至千里，不积小流无以成江海，依然fighting。。。