关于业务系统的架构思考

最近参与了很多的业务系统架构的讨论，有很多收获，也发现了很多不同领域的问题或解决方案抽象起来是一致的，这里做下简单的总结。

一、不能将团队边界、领域边界混为一谈

我们的人员是高效利用的，领域与团队间是不能一一对应的。绝大多数时候领域的边界是不变的，而团队的职责在不断调整，一个团队也很有可能是因为项目而设置，这个时候不能因为团队边界就去改变领域边界。

当我们遇到"冲突"时，应该先聚焦在领域边界，忽略团队边界，应该从如果大家是一个团队，大家一起想架构方案会是什么样的方案。确定了方案后，再思考团队分工。

大家试试，真的可以解决很多问题哦！

二、架构的核心问题就是分层和边界问题

分层的本质就是将变化分离，让每一层独立变化，不用影响全局。分层可以缩小讨论范围，有利于更聚焦于问题本身。软件分层还是一种最佳实践。

这里想强调一下分层和边界定义对我们这样工作环境的意义，业务是在发展变化的，软件一定跟着一起变化，而我们今天的业务形式变化常常会让你无法在教科书中找到"正确"的架构设计，这个时候分层可以让我们把确定性的东西想清楚，封装好。让我们把精力花在不确定性的地方。

如果我们讨论复杂的业务和架构问题时，摸不清头脑，那就先进行分层，是我个人的实践方案，感觉很有用

三、架构的核心问题也是问题定义或领域分析的问题

正确的问题定义和领域定义最接近于问题的本质，当然也是对问题发展方向支撑最好的。面向对象设计思想也解释了这一点，面向对象就是一种能够让我们把问题和领域分析清楚的方法。

我这里想突出一种场景，当问题定义错误，领域划分错误，这个时候如果有另外的领域依赖了本领域，那就是个灾难，这个雷埋给了所有直接或间接信任你的人。

四、架构是一种平衡，不能一刀切

问题的解决方案往往是Hybrid模式的，这个不能理解为妥协。这里面主要想讲的跟第一条的核心思路相依，也与第二条相关。就是我们往往不是将软件分层去讨论，而是拿着两个完整的域或系统去讨论，而很多的冲突是不同层之间的。我们应该针对不同层提出不同的解决方案，形成一种Hybrid的方案。最终达到一种非妥协的平衡。

五、大数据时代，架构多了一种选择，很多可以变成一个优化问题。问题从定性变成了定量。

软件世界常常存在矛盾，比如CAP的矛盾。但今天在大数据时代，结合实时技术，我们可以将矛盾的某一个方面拿出来，从定性改为定量，经如一致性，假设我们的一致性能做到99.9999%，也能让一致性影响的用户范围永远小于个位数，可能就够了，而这个对于一致性的"放弃"，很可能节省了巨大的人力和基础设施成本。这方面AE的区域化部署技术在一致性解决上面就采用了这样的思路。