一提起产品架构，在咱们茶馆的老读者想必第一时间都会反应上来一个词——企业架构。
什么？什么是企业架构？？
国际标准组织（ISO/IEC/IEEE 42010）定义
企业架构（EA）是“对组织结构和行为（包括业务流程、信息系统、技术设施）及其演进原则和标准进行整体性描述的系统化方法”，旨在实现战略目标与技术执行之间的对齐。
而根据TOGAF（开放组架构框架），完整的EA包含四个层级：
架构域 | 核心关注点 | 输出物示例 | 与现实世界类比 |
业务架构 | 组织能力与价值链 | 业务流程矩阵/组织能力地图 | 城市规划中的商业布局 |
数据架构 | 信息资产治理与流转 | 数据实体模型/数据流图 | 城市供水管网系统 |
应用架构 | 功能模块与系统交互关系 | 系统功能模块/服务清单 | 医院/学校等具体建筑 |
但是真正我们做的产品不是每一个都能用上企业架构这么大的框架。
所以今天我们就给大家分享一个最简单且实用的公式来帮助大家快速搞定工作中的规划难题。
这里就要用到我总结的一个公式：三明治架构模型。
01三明治架构：产品视角的极简分层模型
话不多说先上公式！
三明治架构 = 底座面包(基础服务) + 馅料(业务逻辑) + 顶座面包(客户服务)
层级 | 定位 | 关键能力 | 产品设计关注点 |
顶层面包 | 客户服务层 | 交互体验/触达渠道 | 用户旅程触点设计 |
核心馅料 | 业务逻辑层 | 领域规则/流程引擎 | 业务实体关系建模 |
底层面包 | 基础服务层 | 技术能力抽象 | 可复用服务能力解耦 |
那如果用大白话来说就是：就像现实中的三明治——底层面包承托整体（基础设施），馅料决定核心风味（业务价值），顶层面包接触用户（交互界面），各层独立互不打扰，在任何一个新产品中，我们只需要替换馅料就可以快速生产一个新的“三明治”产品了。
02分层设计实战：从需求到架构的拆解路径
搞懂了公式，我们来具体看看每层的逻辑与每一层怎么设计。
层1：设计底层面包——基础服务层
在公司内完成一次基础服务的定义，封装技术复杂度，向上提供标准化能力，并且在后续新的产品中都可以直接使用。
设计方法：
? 定义原子服务：如用户鉴权、消息推送、账号体系（例：SSO所有业务模块调用统一身份认证API）
? 制定能力边界：禁止业务逻辑层直接操作数据库（例：如果库存管理能力是一个基础服务的话，那订单服务只能通过"库存能力API"扣减库存，而不是直接写代码扣减库存）
核心来说此层定义的任何逻辑都能不包含任何业务规则（如"满100减20"），仅提供基础能力支持，业务逻辑将在“馅料层”完成。
层2：填充核心馅料——业务逻辑层（需求分析的主战场）
这一层其实就是不同产品的差异化所在的地方了，承载每个核心领域的业务知识，实现业务规则闭环，具体实现对应的业务域功能（商品管理/订单管理等）
设计方法：
? 定义业务实体与规则封装
实体建模：识别核心业务对象（如电商的「商品」「订单」「会员」）
规则封装：将多变的业务策略转化为配置参数（如满200减10的促销规则）
? 定义业务流程，并使用规则进行管理和驱动（如用户下单判断消费金额调用促销规则，完成实付金额计算）
那如果大家还是不好理解这几个元素都是什么意思，我再举一个大家天天见的OA系统的报销审批流设计：
-实体：报销单、审批人、费用项
-规则：不同金额走不同审批路径（if 金额>5000 → 总监审批）
-流程：金额规则驱动的流转过程（草稿→提交→不同审批→支付完成）
层3：设计顶层面包——客户服务层（用户体验的「翻译器」）
这里的关键点在于此层是业务逻辑的表达层而非实现层，也就是所有的用户体验都是在这里发生的，通过公司的统一能力去触达用户，比如公司的APP/小程序等。
设计方法：
? 选取触达渠道：我们思考要用什么来完成用户触达
? 渠道适配：同一业务逻辑支持多端差异化呈现（Web端展示详细表单，微信端简化流程）
以上我们这三层我们就快速完成了一个产品的架构设计，而且绝对不会有遗漏，实现完整的产品自闭环。
03最后
其实我们可以看到通过这样的方法，我们可以把产品设计中变的与不变的提取出来，确保我们可以在繁杂的产品中，只专注于自己的领域，从而实现快速的产品架构设计。
