从架构设计到架构师( 二 ) _架构

去理解或者接手其它人负责的项目的时候就好像是自己写的一样。这个时候就消灭架构了，就好比现在没有人会教你如何吃饭一样。（就当YY一下吧：）。）

三、做架构的最佳实践上面提到更多的是做架构的目的，那么要做好架构，主要就是要做好抽象，做抽象的方式是类比，做类比的方式可以使用用例图。
所以建议大家多画图，通过画图来将大脑中抽象的结果直观的体现在前面，再来进一步分析合理性。主要推荐2种图的类别，一种就是前面提到的用例图。
如下图：

文章插图

另外一种是鲁棒图，如图：

文章插图

整个过程的主要目的是：

描述其与外部实体（系统和最终用户）的交互。
标识系统和外部实体间的信息和控制流。

最后附一篇之前整理的《软件开发中会用到的图》的文章地址，有兴趣的同学可以扩展阅读下：
https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html 。

理想的世界里，我们程序的边界设计恰好匹配于业务边界。然而我们作为工程师首先要承担业务需求的压力，只能挤时间去做这些非业务性工作。也因此老项目的业务边界也并不总是如新项目那样明晰。
这意味着做任何架构的改动要考虑优先级，特别在拆分业务领域之前认真地思考业务的边界。
排定优先级，考量拆分的收益与风险。划分业务的边界，则需要更多的思考拆分后的未来将如何沟通协作，然后再考虑技术因素。
在技术因素前，主要考量这几点：

是否拥有独立的团队来维护，以及是否拥有发展为一项独立业务的潜力。（非必要的情况下，一定要避免共享内核的开发方式）
围绕领域而非 feature，有明确的维护团队，避免过于细粒度。
拆分或者组合之后，能否改善现有的协作流程。
能否帮助区分核心、非核心业务，改善稳定性。

上面这些完成了之后，便是选择合适的中间件、技术框架来满足技术层面的要求，这个的选拔主要以下面几点来考量：

如果是直接引入第三方的中间件的话，成熟度如何？是否有大公司在用？（有大公司的口碑背书的肯定大大加分）
近期的社区活跃度如何？（用于考量是否有更多的人在一起踩坑，降低各自遇到坑的数量和概率）
硬指标，当前场景的硬性要求是否满足。如性能、对关键部分或者未来的可扩展性等。
软指标，复杂度、可维护性等。这里可以罗列几个竞品的优劣势。
最重要的是要自己去亲自验证上面的几点，并且做一定的模拟工作。
如果曾经用过或者有其中一部分的经验可复用，这是加分项，毕竟在使用的过程中才发现hold不住它，那是灾难性的！

四、什么是好架构之前有听到过一句话，概括的很精辟。
好的架构必须需要贴合业务，那么把业务+技术演变成一个数学公式来表达可以理解为：2个数字的和等于10，求如何组合能得到最大的乘积。那不是3*7，也不是4*6，而是5*5 。

文章插图

所以架构不是生搬硬套，为了架构（搞事情）而架构，赶时髦，或者说装X 。我们应避免通过个人的主观意愿来主导。
比如自己觉得某个中间件好，就”拿着锤子到处找钉子“，这一敲下来，看着不错，但是带来的成本和风险被忽略了。可能有更好的解决方案，或者完全没必要在当下敲这一钉子下去。
好的架构需要评判投入产出比，收益更高的就是更好的架构，就如下图的公式。
产出可以理解为我们因此获得的好处（诸如可靠性、安全性、可扩展性、可维护性、可伸缩性、性能等），成本是我们改造花费的投入，如人力物力和时间。
特别注意的是风险这点，是很重要也是很容易被大家忽略的一点，是起到指数级作用的。
选择的方案再好，如果都是一些hold不住的技术，那么风险就是无穷大，导致减号右侧无限趋近于0，最终的结果就是收益是负数，投入的成本打水漂，甚至还要加上其它额外的付出。