设计模式与分布式架构实战总结

在当今快速发展的软件工程领域，掌握设计模式和分布式架构对于构建高效、稳定、可扩展的系统至关重要。以下是对相关内容的进一步分析和梳理，供大家参考。

架构设计的哲学：NP问题的现实映射

什么是NP问题？

NP问题是计算机科学中的一个重要概念，它代表了一类可以在多项式时间内验证解，但难以在多项式时间内求解的问题。
举例来说：

旅行商问题（TSP）：一个经典的NP完全问题，它要求在给定的一组城市和每对城市之间的距离时，找到一条最短路径，使得每个城市只访问一次并最终回到起始城市。
背包问题（Knapsack problem）：一个典型的NP问题，它要求在给定的物品和背包容量下，如何选择物品装入背包，使得背包中的物品总价值最大。

对于架构设计来说，你给我方案，我可以说：好不好？至于最合适的方案：真不知道。那ChatGPT未来可以替代架构设计工作吗？
在这里插入图片描述
架构设计中人的因素更重要，受到的软性约束条件也更多。对于人来说，要考虑的有以下几个方面：
机会考虑:
最近的技术热点框架、突然而至的政策红利
欲望考虑:
是否有利于晋升或加薪、是否有利于申请优秀项目
取舍考虑:
取与舍的灰色地带的处理、舍的代价是否可以承受、系统的熵增来自于胆怯和懒惰
在这里插入图片描述

架构设计被形象地比作NP问题，它反映了在多种可行解决方案中寻找最优解的复杂性。架构设计不仅仅是技术选择，更涉及到决策者的心理、期望和人性考量。架构设计中的“欲望动机”、“取舍分析”和“设计能力”构成了决策的三个维度，它们共同影响着架构的最终形态。

企业战略与架构的深度融合

明确架构的目的是什么？

在这里插入图片描述
战略与架构有什么关联？

架构设计的流程

确定边界
确定系统边界，在技术层面上做与不做
确定关系
确定系统里各模块之间的依赖关系、模块与环境之间的关系
可扩展性
后续的子系统或模块设计，在一个既定的框架内和技术方向上继续演化
非功能性要求
明确非功能性需求是指高可用、高并发、安全性等

战略从问题出发，抽象问题模型和核心元素，制定业务策略。问题域是系统存在的缘起，透过现象看本质问题、抓大放小、任何问题都反映着用户痛点。业务域的产物业务功能树和业务架构图，有哪些功能的存在和组合能够解决问题域提出的用户痛点;业务架构图反映企业战略和定位，中观上反映核心要素和系统的行为

问题域和业务域是重中之重，是道，而技术域是术

订票系统为例

业务战略：从0到1的系统，使得火车票的发售和检票更加方便、更加安全，提升旅客的乘车体验;通过票务数据和实际载客量，优化铁路运行线路和时刻表;在旅途中，通过餐饮、住宿、打车、商城等延伸消费场景，提升平台的边际贡献。

业务需求：

旅客通过平台注册和登录，实名认证后，然后购票，推荐酒店和约车;
检票系统的闸机能够通过接口获取到购票信息和身份证信息;
在乘车过程中可以通过座位前方的二维码点餐，预定酒店和车辆，景点门票等，提供注册铁路会员即可免费接入WIFI服务;
发放优惠劵吸引用户到铁路商城购物，填写邮寄地址，免费送到家;
通过会员等级和积分权益打造旅客的忠诚度和APP打开率:
优惠购票通过身份类型来界定，退票按照时间规定实行阶梯价退票。后台系统有能力修改车站、车次、票价设定，并且管理铁路商城类目和上下架。

其他要求：只要符合业务战略，可以补充和延伸业务需求，做到架构逻辑自治。

同理也要考虑K3订票系统的问题域
在这里插入图片描述
业务架构图

企业战略与架构设计是相辅相成的。通过“从问题域到技术域的演进路线”，展示了如何将业务需求转化为技术实现，以及如何通过架构设计来支持和推动企业战略的实施。业务架构图、数据架构图和产品架构图等工具，帮助我们从宏观角度把握系统的整体结构和发展方向。