架构愿景：建设能支撑业务XX年发展的业务系统（无代际）
内核的不变性：业务的变化是界面、流程、逻辑、规则的变化，基础业务要素对象不变。如人、货、场、订单等
结构的不变性：内核是灵魂，结构是身份标识，好的结构应该是快装快拆（0成本下线、灵活组装）
API的不变性：API即是生命周期，面向对象抽象，需要考虑到数据扩展，在多场景下，可对API分层
组件的隔离性：隔离是隔离变化，面向领域高内聚，组件应该是无状态（自包含），可以任意组合扩展（理想态）
关键挑战&应对思路
-
从业务视角将下单系统分为4层，这每一层会形成一个天然的屏障，将不同的需求过滤掉，越上层的改动成本越低，所以我们需要不断提升上层需求的占比。上面2层主要是用扩展和配置化的方式来支撑不确定的需求，下面2层主要是平台能力抽象，从而实现平台跟业务分离。同时也实现了对需求变化的屏蔽。我们假定的是平台的逻辑是抽象沉淀通用逻辑，在新的需求场景来的时候，平台层也基本是可复用的。在这个角度需要2个关键点做好，一是平台逻辑的抽象建模，需要保障高复用，另一个是平台层是可扩展的。
-
平台层的设计方向是收敛稳定的，平台层的核心目的是确保复用，代表不断变化的需求背后不变的部分的沉淀；业务层的设计需要是开放的，业务层的主要目的是用来支撑不断变化的需求。
-
扩展性是用已知能力去支撑未来需求的关键设计，扩展性可分为4种：1是业务逻辑的扩展，通过扩展点来实现；2是数据的扩展，需要支持模型扩展来实现；3是流程的扩展；4是界面的扩展，需要支持界面的配置化搭建，通过组件化来实现。能力的抽象需要有高复用和可扩展性，基于领域对象进行抽象，进行子域拆分，将逻辑的变化按子域对象进行收口，并进行扩展性设计。
-
在日常研发中，需要严格来按照需求渗透的模型角度进行方案的设计，上层扩展实现优先，架构师同学需要做好设计把控。
-
业务层按垂直业务和横向业务拆分，垂直业务因为有了确定的业务身份，将业务身份相关的扩展逻辑进行聚合，天生可以做到相互隔离，隔离的本质就是隔离了业务间的变化，避免业务之间相互影响，从复杂度分析看，业务的无限增长是线性规模，是一个常数级复杂度，对系统复杂度并不会有影响；横向业务是跨垂直业务可复用的扩展集合，需要与业务相互叠加，同时横向业务之间也需要叠加，是一个指数级的复杂度，并且随着横向业务的数量不断增加，会变的很难以分析也不可维护，因此横向业务也需要有确定性的身份条件，并且需要非常严格的限制横向业务的规模，才可以很好的控制系统复杂度。在日常设计过程中，需要合理的考虑业务身份优先。
-
业务逻辑按子域拆分收口，子域内部抽象沉淀复用逻辑，面向子域的内部模型进行扩展性点开放设计，需要做到扩展点的数量的收敛性，扩展点不断扩张的子域是一个非常不稳定的子域。因此扩展点的开放是需要面向子域模型，而不应该是面向资源和流程抽象，如果面向资源抽象会导致子域本身的不稳定性，这是需要持续守护的关键点。
-
下游资源解耦，隔离下游系统变化对下单产生侵入式冲击，在下单与下游系统之间确定标准化的交互协议，技术上通过IOC进行解耦，需要共享模型（标准协议）基础，在更理想的情况下，上下游直接打通共享模型的透传，并且天生具备了模型扩展的特征，这是一个长期的演进方向。
-
稳定性提升，将系统日志按业务身份、能力编码进行埋点，可以做到按业务进行监控告警和问题排查，同时可以将监控告警分为平台视角和业务视角，在业务视角层面，可以做到垂直业务身份的精细化维度，这一方面可以快速定位到有问题的业务场景，还可以快速评估出影响面；比如说一个平台级的报警影响面会是全局的，业务身份的报警是局部的，这也是在分离复杂度。对于小流量的创新型业务，可以按业务身份进行精细化的运维，否则在大盘的大数据量下，小流量的业务报警非常容易被大盘报警淹没，而导致业务问题反应迟钝。
原则：通过简单通用的原则确保架构复杂度不过度劣化，给日常研发设计提供方向性指导
-
业务扩展原则：优先在业务层扩展实现业务需求。配置化优于扩展点扩展，扩展点扩展优于流程扩展。应该尽量避免在场景能力内使用流程扩展。
-
业务抽象原则：尽量要有明确的生效条件，垂直业务抽象优于横向业务的抽象
-
业务优先原则，在有争议和不确定的场景下，优先用垂直业务进行设计，避免场景能力的过度膨胀，带来的复杂度的扩散。
-
业务需要有明确的生效条件，垂直业务身份识别条件一般是确定的，场景能力的识别条件存在一定的动态性；业务需要强的确定性，而确定性是静态的，这样才可以更容易的进行系统分析，增强业务的确定性，否则会存在较大的线上资损风险（动态变化的规则是难以分析和模拟的）。
-
将经营业务身份与系统业务身份进行解耦，通过营销身份和系统身份的动态绑定，提升双边灵活性？
-
-
平台沉淀原则：控制扩展点数量，不随意增加扩展点。比如可以采用加一减一的原则。增加一个扩展点的同时需要减少一个扩展点。尽我们最大的努力去控制扩展点的膨胀问题，同时去倒逼大家在日常设计时的惰性，因为增加一个扩展点的成本和风险都极低，这是大家最喜欢的方式，但是会持续带来系统复杂度的发散，导致领域架构最后的难以解释和不可维护。
机制：在日常中通过流程机制保障架构完整性
-
在日常研发中，加强概要设计环节的落实，增强研发架构意识，减少详设评审时长，避免错误设计引起时间的损失
-
建立架构能力度量模型，对架构进行数据化，形成下单系统架构基线数据，用数据化的方式对架构进行科学性的评估，并定期进行架构效果Review，并用科学的手段指导架构的优化迭代，同时避免个人的主观偏好对架构产生入侵腐化。
- 架构指标：扩展需求比（含配置需求比），子域渗透（共享模型变更率）、扩展点规模、场景能力规模等
关键解
收敛平台层领域逻辑，优化扩展点设计，收敛扩展点增长，提升扩展点复用性，降低扩展点数量。与下游资源层解耦，抽象共享模型，提升基础能力复用，基础能力做到独立技术输出，前提是要做到外部系统的模型解耦。
加强架构运营：做好方案模板（概设、详设）、流程机制（方案review、cr）、定期进行架构效果评估
对日常需求研发，在流程上增加概设环节（ ），通过概设评估，快速确定架构方案的合理性，概设环节可以做到轻量化，走线下文档化也可以达到目的。
建立下单架构评估模型，形成下单系统架构指标基线，每月定期Review防止劣化
| 类型 | 指标名称 | 口径 | 单位 | 目标值 | 达成率 | 当前值 | 备注 |
|---|---|---|---|---|---|---|---|
| 一级 | 扩展点复用率 | (业务身份数量+能力数量) / 扩展点数量 | % | 50% | 52% | 26% | 架构扩展性 |
| 一级 | 扩展需求比 | (配置化需求+扩展开发需求比) / 需求总数 | % | 60% | -70% | 18.2% | |
| 二级 | 组件化配置比 | 组件配置数 / 需求总数 | % | 30% | - | - | |
| 二级 | 扩展开发比 | 扩展开发数 / 需求总数 | % | 40% | -55% | 18.2% | 包括扩展点、模型、流程扩展 |
| 一级 | 平台渗透率 | 平台层变更数 / 需求总数 | % | 30% | - | - | 除了子域，还包括流程的变更 |
| 二级 | 订单子域渗透率 | 订单子域变更数 / 需求总数 | % | 10% | -233% | 33.3% | |
| 二级 | 支付子域渗透率 | 支付子域变更数 / 需求总数 | % | 10% | -142% | 24.2% | |
| 二级 | 物流子域渗透率 | 物流子域变更数 / 需求总数 | % | 10% | -142% | 24.2% | |
| 二级 | 风控子域渗透率 | 风控子域变更数 / 需求总数 | % | 10% | - | - | |
| 一级 | 扩展点数量 | 扩展点数量加总 | 个 | 200 | -19% | 237 | |
| 二级 | 订单子域扩展点数量 | 订单子域扩展点数量加总 | 个 | 15 | - | - | |
| 二级 | 营销子域扩展点数量 | 营销子域扩展点数量加总 | 个 | 15 | - | - | |
| 二级 | 物流子域扩展点数量 | 物流子域扩展点数量加总 | 个 | 15 | - | - | |
| 二级 | 风控子域扩展点数量 | 风控子域扩展点数量加总 | 个 | 5 | - | - | |
| 一级 | 场景能力数 | 场景能力数量求和 | 个 | 30 | -3 | 33 | 控制复杂度，防止快速膨胀 |
| 二级 | 流程扩展比 | 流程扩展的能力占比 | % | 0% | -6% | 6% | |
| 观测 | 业务身份数 | 业务身份数量求和 | 个 | - | - | - |
架构的长期价值
有了稳定的顶层设计后，可以对系统架构做数字化建模，形成系统架构的数字化模型资产，以架构模型为中心，可以很好的连接软件全生命周期，从需求结构化、需求分析、系统分析、系统设计、代码开发、自动化测试、发布运维等阶段进行提升突破。
