设计软件程序的时候，组件尽可能独立，而只有很少几个可控的依赖项。
每个组件只负责关注自己擅长的领域。专业化，易扩展，可维护。
从而达到各个模块，如能工巧匠各司其职。模块调度如文武百官各就其位。

在理想情况下，每个组件都不了解其他组件，而只是通过抽象接口来处理应用程序的其他区域。
这称为松耦合 。它能够使应用程序更易于测试和修改。

举个简单常见的例子：

很多时候，我们都喜欢把 用户 登录名，登录密码哈希值，手机号，余额，积分， 等字段全部放在一个用户信息数据表 user 。
很多开发者一直是这样做的，因为没发现什么问题，而且这样非常方便快捷。

好一点的工程师，知道这样做有点不规范，但也不一定能说出个所以然。
为什么即使所有的用户信息字段，都是一一对应的关系，却不推荐放一张数据表里呢？仅仅是因为一张表字段太多，横向发展，看起来又臭又长？

因为，根据软件工程的关注分离和松耦合的设计思想，不建议这么做。

打个比方，看如下需求：

平台要从10万个用户里面，筛选出最近余额或积分有变动过的用户，排查资产变动是否有异常。

请注意，这个需求是在开发已完成，项目运营一段时间之后，提出来的。
基于开发习惯，我们通常会在每个数据表，增加几个维护字段方便管理数据。
例如 created_at updated_at deleted_at 用于数据模型维护每一条数据的创建时间，更新时间，软删除时间 等。

方案一：
查找资产变动记录明细数据表，再关联所属用户信息。理论上，能筛选出正确结果，但耗费资源，操作繁琐。

方案二：
通过 updated_at 字段，直接从用户信息数据表，筛选出最近时间段，数据有过更新操作的用户。
方便快捷，虽然结果不准确，但也误差不大。因为可能会筛选出最近改过登录密码的少量用户。但，如果用户信息user数据表，里面的字段又臭又长，远不止前面提到的这几个。那任意字段的变更，都会触发 updated_at 字段的更新。筛选结果就不准了。

用户资产，这是我们的一个关注点，却和其他用户信息混合在一起。比如：邮箱验证，实名认证，密码，手机，地址信息，粉丝数量，甚至个性化设置，存放在一个数据表。这就是关注点不分离。

一般情况，用户的 手机号， 登录名，登录密码哈希值，较少变动。而对于活跃用户，积分，余额 字段，可能经常有增减。

关注点分离：
用户登录名，密码，手机，邮箱基本信息存一数据表。因为邮箱，手机，登录名，都是唯一可用于登录账户。
新增 用户资产 user_property 数据表，存放不可用余额，可用余额，积分等用户资产。
用户个性化设置，放入 user_setting 数据表。甚至连 粉丝数量和个人动态发表数量（发布文章数量），也可分离出来。

方案三：

通过 updated_at 字段，直接从用户资产数据表，筛选出最近时间段，资产数据有过更新操作的用户。

下面其他需求也可轻松应对：

最近改过密码或手机号和邮箱的用户；最近改过个性配置的用户；前面两个都改过的，为疑似账户风险用户；
最近变动过粉丝数或个人动态发布数量（发布文章数量）为最近社交活跃用户；最近资产有变动，为最近活跃用户。

当然，也不能说分离得越多越好。这个得看具体项目业务和行业需求。这又是一个分离细粒度问题。小项目可以不用做那么多分离。细粒度就大。考虑得多，拆分分离的单元多，细粒度就小。

关注分离艺术 https://www.cnblogs.com/Abbott/archive/2009/02/21/1395407.html

建立松耦合组件 https://www.cnblogs.com/zhangchaoran/p/7545928.html

理论篇：关注点分离(Separation of concerns, SoC) https://www.cnblogs.com/wenhongyu/archive/2017/12/06/7992028.html