最近参与了很多的业务系统架构的讨论,有很多收获,也发现了很多不同领域的问题或解决方案抽象起来是一致的,这里做下简单的总结。
一、不能将团队边界、领域边界混为一谈
我们的人员是高效利用的,领域与团队间是不能一一对应的。绝大多数时候领域的边界是不变的,而团队的职责在不断调整,一个团队也很有可能是因为项目而设置,这个时候不能因为团队边界就去改变领域边界。
当我们遇到"冲突"时,应该先聚焦在领域边界,忽略团队边界,应该从如果大家是一个团队,大家一起想架构方案会是什么样的方案。确定了方案后,再思考团队分工。
大家试试,真的可以解决很多问题哦!
二、架构的核心问题就是分层和边界问题
分层的本质就是将变化分离,让每一层独立变化,不用影响全局。分层可以缩小讨论范围,有利于更聚焦于问题本身。软件分层还是一种最佳实践。
这里想强调一下分层和边界定义对我们这样工作环境的意义,业务是在发展变化的,软件一定跟着一起变化,而我们今天的业务形式变化常常会让你无法在教科书中找到"正确"的架构设计,这个时候分层可以让我们把确定性的东西想清楚,封装好。让我们把精力花在不确定性的地方。
如果我们讨论复杂的业务和架构问题时,摸不清头脑,那就先进行分层,是我个人的实践方案,感觉很有用
三、架构的核心问题也是问题定义或领域分析的问题
正确的问题定义和领域定义最接近于问题的本质,当然也是对问题发展方向支撑最好的。面向对象设计思想也解释了这一点,面向对象就是一种能够让我们把问题和领域分析清楚的方法。
我这里想突出一种场景,当问题定义错误,领域划分错误,这个时候如果有另外的领域依赖了本领域,那就是个灾难,这个雷埋给了所有直接或间接信任你的人。
四、架构是一种平衡,不能一刀切
问题的解决方案往往是Hybrid模式的,这个不能理解为妥协。这里面主要想讲的跟第一条的核心思路相依,也与第二条相关。就是我们往往不是将软件分层去讨论,而是拿着两个完整的域或系统去讨论,而很多的冲突是不同层之间的。我们应该针对不同层提出不同的解决方案,形成一种Hybrid的方案。最终达到一种非妥协的平衡。
五、大数据时代,架构多了一种选择,很多可以变成一个优化问题。问题从定性变成了定量。
软件世界常常存在矛盾,比如CAP的矛盾。但今天在大数据时代,结合实时技术,我们可以将矛盾的某一个方面拿出来,从定性改为定量,经如一致性,假设我们的一致性能做到99.9999%,也能让一致性影响的用户范围永远小于个位数,可能就够了,而这个对于一致性的"放弃",很可能节省了巨大的人力和基础设施成本。这方面AE的区域化部署技术在一致性解决上面就采用了这样的思路。