先看在 ISO/IEC/IEEE- 42010:2011 标准中对于架构的定义是
“架构是系统在其所处环境中的基本概念或属性，体现为它的元素、关系，以及系统设计和演进的原则。”
包括静态结构和动态演进，所以架构也分两派，“结构派/组成派”强调架构是组件及构成关系，“决策派”强调架构是一些重要决策集合，我们需要结构也需要演进中的决策。建筑如果决策正确，可以立足百年，而软件software就是soft，容易改变，是一个不断变化的领域，它的成功与否取决于代码的状态、最初编写时的质量，以及不断变化的业务环境。发明软件的目的是为了使硬件的行为易于改动，软件是用户与硬件之间的接口界面。
所以，我们要的是在没有结构的时候，找到或预见“结构”；在需求变化需要演进的时候，基于“结构”做新的决策。而“结构”就是基于相对稳定的“要素”去构建的，需要我们去区分“变”与“不变（相对稳定）”，这样也是软件设计的一个基本原则。
如何区分变与不变、划分边界、确定关系、建立模型，以及常见的一些架构/方案在应对什么问题，围绕这些话题做一点分享。
从已有专业领域找结构
比如我们做企业管理、零售、供应链等软件架构设计时，这些专业领域都已经存在已久，有很多成熟体系，可以直接拿来框一下，对理解业务会有很大帮助。
业务分析框架
例如经营的基本逻辑“收入-成本=利润”，收入和成本构成随行业、产品、业务模式不同而不同。《ThoughtWorks现代企业架构框架白皮书_V4》的业务架构的业务全景梳理也用商业模式布，就是一种较为通用的分析框架，把一些事项对号入座，划分大边界，就开始有结构。
业务专业的基础理论
例如《营销管理》这本书牛在基本涵盖了营销的各个领域的完整的一本书，对建立基础认知也非常有帮助，你就不会去随意定义“渠道”，它也不仅仅是一个普通的枚举。
1. 营销人员通过3种渠道与目标市场接触，传播渠道（communication channel）、销售渠道（districtibution channel）、服务渠道（service channel）。
2. 营销者基于渠道的目标和约束，例如渠道的顾客群、渠道成本、效率、渠道管控能力等等，来选择渠道，设计渠道系统。
3. 营销渠道系统是指商品从生产领域转移到消费领域所经过的各个环节和营运通道紧密联合的有机组织体系。组织体系分为：垂直渠道系统、水平渠道系统、多渠道系统。
4. 营销渠道系统按中间商层级的多少，又可以分零级渠道、一级渠道、二级渠道、三级渠道。
5. 营销渠道系统按照流向，还可以分正向渠道（从商家到消费者）、逆向渠道（例如一些产品的回收，从消费者到商家）。
6. 触点是你的品牌、产品、服务等在各个方面各个环节与用户的接触点。
图PS：模型还是要根据场景
识别原始素需求
例如商品管理，我仅看功能往往看到的是商品管理，增删改查，好一点可能会说是分发、上架、下架、清退。但商家操作背后的逻辑是什么，是怎么选品、管理商品周期、如何提效等等的呢？跳出系统功能从企业经营层面去理解下商品管理的业务，可能有更多的思考，++一般原始需求是相对不变++，而实现形式可能是不断变化的，理解对了大方向和关键设计不太容易错。下面举几个业务角度的理解，可能会跟我们平时了解的不一样。
例1:店铺的商品结构管理
酱油这个小分类，如果说配置总共是20支，普通性且认识度高的要配置12支，酿造及功能性的配置6支，再略高端的酱油就配置2支左右。这一类商品结构模型商品结构，适用于消费力相对于较低的城乡结合部，老城区，城中村周边的超市。
例2:店铺的商品流动性管理
Q：超市开在部队及一些相对封闭的基地、校园区旁。那这里的商品变动率要求是快还是要慢呢？
A：商品的变化一定要快。封闭式也代表着生活圈小，商品卖得好，你有我有就不稀奇啦，封闭式最大的是给人带来的无聊感 ，逛超市也是他们休闲的一种方式，你超市里商品的更换流动速度越快，他们来的频次也就会更高，那必然是销售的越好。
例3:商品管理部门的工作内容
1.商品采购：选品、评选供货商
2.控制商品存货：预算计划、分配商品到店铺、库存量管理
3.商品定价：定价、调价等
把业务任务从流程里解耦
一般业务任务是相对稳定的，而业务流程是经常调整的，不要让【业务任务】的处理逻辑去依赖【流程或上个任务相关东西】。
例如交易流程里有下单、付款、发货，一般最开始场景先付款再发货。而货到付款是先发货再付款，流程就不一样，而付款方式也是不一样。
普通订单：待付款 → 已支付 → 待发货 → 已发货 → 确认收货 → 交易完成 → 全额退款 → 订单关闭
拼团订单：待付款→ 已支付 →【 待成团 → 已成团】 → 待发货→ 已发货→ 确认收货→ 交易完成
虚拟商品订单：待付款 → 已支付→ 【电子卡券生成】 → 已发货→ 确认收货→ 交易完成
酒店订单：待付款→【待接单-->已接单-->确认入住】→ 已支付→ 交易完成
虽然在业务初期很难预测后续业务发展，但是不影响把步骤对应的业务任务与流程尽量解耦。后面逐步做重新演进规划，例如订单状态流转的基本逻辑：
1. 拆分支付和履约两子流程，它们内部流转比较确定，并可以整体互换的。像酒店的履约【待接单-->已接单->确认入住】可以整体替换【发货履约：待发货->已发货->确认收货】。
2. 允许中间可以增加状态，例如【待拼团-->已拼团】。
3. 允许有些状态是可以跳过的，比如下单后直接跳转待付款。
4. 允许扩展自定义状态，比如拼团的订单状态，由拼团自己独立维护，订单上可以提供扩展状态。
识别必然耦合和偶然耦合
例如我们第一次做微信私域商城，支付是微信支付，但是我们直接支付，那么做支付宝小程序的时候，可能就改动比较大。这里交易上我们需要一个支付能力是必然耦合，而具体的微信/支付宝支付是偶然耦合，是变化的。支付能力--线上/线下支付能力--具体支付方式，我们必然耦合的是哪一层是要留意去识别的。这种例子随处可见，比如我们需要发通知，可以是短信、也可以是飞书、企助消息提醒。
通过深化对业务的理解，我们从业务上找到了业务真正所耦合的能力，然后将其他具体的供应商隐藏在能力之后。这样我们就完成了从偶然耦合到必然耦合的重构。注意，这个操作的关键在于，我们从业务上寻找到了对应的业务能力。
分层架构
定义如下
分层架构，是依据隔离变化原则，将软件组件（广义）依据纵向结构进行分层组织的架构方式，其中上层能够依赖或者调用下层，下层对上层一无所知，每一层都对自己的上层隐藏下层的细节。
功能属性和质量属性
一般说，软件包含功能属性和质量属性（非功能属性），也是一种“分层”架构。
1. 功能属性是从业务需求出发的解决方案，保证如何做“正确”，需要理解其包含的最重要的业务知识，包括我们所说的业务流程、组织架构、行业规则、领域知识等等。这些知识描述了软件是如何帮助客户解决某一类问题，或是一家企业是如何运营其业务的，或是以何种形式与用户互动等等。
2. 质量属性是从技术视角出发的解决方案，保证如何“正确得实现”，是针对性能、可靠性、可扩展性等问题的解决方案。
应用间与应用内分层
应用间常见的就是应用层、业务中台、技术中台、数据中台这种分层架构。隔离各自需要去解决的问题。技术中台去应对一些非功能性需求的变化，比如流量洪峰、性能、弹性需求等，也隔离一些底层硬件、网络差异带来的影响；业务中台去应对一些功能需求的变化，让一些能力能复用，避免低水平重复建设。也可参考：重新聊聊"业务侧与技术中台的边界、标准推进”问题
常见的应用内部分层结构，就是三层架构及以领域为核心的六边形/洋葱/整洁/菱形架构。
分层帮助识别不同的关注点，完成层间的解耦，各自独立聚焦各种重点发展，为我们提供清晰的指导，帮助我们在适当的层次上设计自己的抽象概念，有效地分离了各个关注点，从而让整体更好的响应业务发展。
领域划分、微服务架构
DDD介绍了一种将大问题空间分解为领域或重要实体（如客户和订单）及其关系（客户下订单）和行为的技术。领域定义的一部分是有关边界上下文的概念：每个领域形成一个围绕实现细节的封装层。
例如，如果分析人员识别了一个Customer领域，那么它存在于自己的边界上下文中。在Customer的上下文中，开发人员知道所有的实现细节：类结构，数据库模式等。
但是，其他边界上下文（如Orders）不能看到这些实现细节。虽然领域可以为了协调的目的互相发送消息，但是任何一个领域都不能穿透另一个领域的边界上下文。
因此，在一个边界上下文中的开发人员可以自由地更改实现，而不必担心破坏其他领域。微服务中的容器是领域驱动设计（DDD）中边界上下文的物理表现：每个容器代表了一层封装，以防止实现细节干扰系统的其他部分。
所以，微服务的边界应该是基于领域边界、弹性边界来建立的物理边界，但实践情况挺糟糕，出现有很多分布式单体，该内聚逻辑被分散到不同的微服务里，一次需要要改很多个微服务，而微服务真正的特性没有得到应用，这些更强制的物理边界没有起到隔离变化的作用，反而增加维护、研发的负担。
上图划分逻辑不一致，没有考虑“领域重要实体、及其关系、行为。例如查询上下文可能在按功能模块在划分，它的领域对象是什么？搜索上下文按技术实现划分？等等问题。
想提醒的是
1. 单体并不是敌人，微服务也不是默认的选择。
2. 微服务架构是因为它具有独立部署的特性，这是微服务的黄金法则。
3. 我们能定义边界后，还要去维护边境，而微服务的物理边界，一定程度还能很好的帮助维护边界。
所以微服务架构，本质是用技术上确定性，来应对业务的不确定性，通过抽象和设计进行合理划分，隔离缩小变化范围，以应业务需求的不稳定性，如果设计和划分不对，那么这个也不成立。
减少对不稳定变量的依赖
如果公司发展有多个产品线和业务线的时候，往往系统就开始定义业务线、产品线这种全局变量，以区分他们的逻辑差异，很多团队很多领域的代码，大量的根据这些变量进行IF ELSE判断和处理。而这些变量变化很快，另外定义往往也不准确和不易管控，比如有时根据部门、有时根据产品。而这些变化都很快的，不然不会有这么多比较重要演进需求。
后来开始引入业务身份，根据业务身份进行建模。
目的:为满足不同的业务运营需求，对影响业务运营规则的各维度进行识别，并组装成为唯一标识。
业务身份由“业务身份ID”“业务身份名称”、“业务身份要素定义”“业务身份识别解析规则”四个部分组成。其中，业务身份要素定义是最基础、也是最难的部分。
企业应根据自身业务特征对身份要素进行识别定义，常见的身份要素维度包括但不限于:客户、产品和渠道等。
业务身份要素除了对要素维度进行抽取识别，还需要定义每个要素维度所包含的领域对象(包括领域对象的属性)，这些领域对象及其属性用来定义业务身份的识别解析规则。
想到什么写什么，零零散散的一些分享，仅供参考。
·············· END ··············
往期文章精选：
1.业务分析
