后端架构中，SOA（面向服务架构）和BFF（为前端服务的后端，Backend For Frontend）因“职责分层清晰”“解耦前后端”等优势被广泛推崇，但并非所有团队都会采用，核心原因在于架构选型需匹配团队规模、业务特性、技术能力及成本收益——清晰的分层往往伴随额外的复杂度、开发成本和运维开销，当这些“代价”超过“收益”时，团队会优先选择更务实的方案。

要理解这一现象，可从“业务场景不匹配”“成本收益失衡”“技术能力不支撑”“历史包袱制约”四个核心维度拆解，具体如下：

一、业务场景：SOA/BFF的优势在部分场景下“无用武之地”

SOA的核心价值是“服务复用、跨系统协同”，BFF的核心价值是“适配多端（Web/APP/小程序）差异、简化前端调用”。若业务不具备这些需求，分层的意义会大幅降低，典型场景包括：

1. 小型业务/单端场景：BFF层成“冗余层级”

若团队仅服务单一前端端侧（例如仅做内部管理系统，且只有Web端），前端需求稳定、接口调用简单（无需适配多端的参数格式、权限逻辑、数据聚合规则），BFF层的“适配价值”会完全消失——此时直接让后端接口对接前端，反而减少“前端→BFF→后端服务”的调用链路，降低延迟和故障点。

例如：一个10人以内的小团队开发“公司考勤管理系统”，仅支持Web端，功能是“打卡记录查询、请假审批”，接口需求固定（无需适配APP的轻量化数据、小程序的授权逻辑），此时引入BFF会额外增加代码量和部署节点，完全没必要。

2. 业务单一且无复用需求：SOA的“服务拆分”成“过度设计”

SOA的核心是将业务拆分为独立服务（如用户服务、订单服务、支付服务），以实现“跨系统复用”（例如“用户信息”可被订单、支付、会员系统共同调用）。但如果业务本身是单一闭环，无跨系统协同需求，拆分服务反而会增加复杂度：

• 例如：一个“工具类APP后端”（如计算器、二维码生成），核心逻辑是“接收前端参数→计算/生成结果→返回数据”，无用户系统、无订单系统，业务逻辑单一且无复用场景，此时用“单体架构”直接写接口，比拆成SOA服务更高效（避免服务注册、服务调用、分布式事务等额外问题）。

3. 业务高频迭代且需求不稳定：分层增加“变更成本”

SOA和BFF要求“提前定义服务边界、接口契约”，但如果业务处于快速试错期（如创业公司的0-1产品），需求每周迭代，接口字段、调用逻辑频繁变更：

• 若用SOA：改一个业务逻辑可能需要同步调整“服务A→服务B”的接口契约，还要协调多服务开发，效率极低；
• 若用BFF：前端需求变更可能直接导致BFF层的“数据聚合逻辑、参数转换规则”重构，反而不如“后端直接对接前端”灵活。

二、成本收益：分层带来的额外开销“不可承受”

SOA和BFF的“清晰分层”是有代价的——需要投入更多人力、时间、资源维护，当团队无法承担这些成本时，会选择更轻量的方案。

1. 团队规模与技术能力：小团队“扛不动”分层架构

SOA和BFF的落地需要配套的技术能力和人力支持，而小团队（如5人以内后端团队）往往不具备：

• SOA需解决的问题：服务注册发现（如Nacos/Eureka）、分布式事务（如Seata）、服务监控（如Prometheus/Grafana）、接口文档管理（如Swagger）——这些工具的搭建、维护需要专人负责，小团队成员往往“身兼数职”，无力承担；
• BFF需解决的问题：BFF层的高可用（避免单点故障）、数据缓存（减少后端服务压力）、接口适配逻辑的复用——若团队无“全栈思维”的开发人员，BFF层可能沦为“简单的参数转发层”，失去价值反而增加故障点。

例如：一个3人后端团队开发电商小程序，若强行拆SOA（用户/订单/商品3个服务）+ BFF层，意味着1人要维护服务治理工具，1人写BFF，1人写业务服务，一旦有人请假，整个开发链路可能中断。

2. 运维与资源成本：分层架构“花钱更多”

SOA和BFF会增加部署节点和运维复杂度：

• 部署成本：单体架构只需部署1个应用，SOA拆3个服务就要部署3个应用+1个注册中心，BFF层还要再部署1个应用，服务器资源（CPU/内存）需求翻倍；
• 运维成本：多服务需要单独监控日志（如ELK）、单独排查故障（如定位“前端报错是BFF层问题还是后端服务问题”），运维人员的工作量会显著增加。

对于成本敏感的团队（如创业公司、内部工具团队），这些额外的服务器费用、运维时间成本，可能超过“分层带来的解耦收益”。

三、历史包袱：现有架构“迁移成本过高”

很多团队不采用SOA/BFF，并非“不想用”，而是“不能用”——受限于历史架构的包袱，迁移成本过高：

1. legacy系统（遗留系统）难以拆分

若团队核心业务基于“单体架构”运行多年（如银行、传统企业的后端系统），代码耦合严重（用户、订单、支付逻辑写在一个工程里），且无完善的接口文档：

• 拆分SOA需要先梳理“业务边界”，但老代码可能无清晰分层，梳理成本极高；
• 迁移过程中需保证业务不中断，可能需要“双写数据”（单体系统和新服务同时运行），风险和工作量巨大。

此时团队更倾向于“在单体架构内做局部优化”（如拆分模块、优化数据库），而非冒险迁移到SOA。

2. 现有团队习惯“单体开发模式”

若团队长期使用单体架构，开发、测试、部署流程已固化（如“本地跑全量代码调试”“一键打包部署”），引入SOA/BFF需要改变团队协作模式：

• 开发时需“跨服务联调”，测试时需“部署多服务环境”，部署时需“按服务灰度发布”——这些流程变更需要团队成员重新适应，短期内会导致效率下降。

对于追求“稳定交付”的团队（如传统企业IT部门），不会轻易打破现有习惯。

四、替代方案：更轻量的架构能满足需求

SOA和BFF并非“唯一解”，很多场景下，更轻量的架构既能解决核心问题，又能避免分层的复杂度：

总结：架构选型的核心是“匹配”而非“先进”

SOA和BFF的“分层清晰”是优势，但这种优势需要在业务有复用/多端需求、团队有能力支撑、成本可承受的前提下才能体现。很多团队不用这种模式，本质是“权衡后的务实选择”——与其为了“架构先进”而引入不必要的复杂度，不如选择更贴合当前业务、团队、成本的方案。

随着业务增长（如从单端到多端）、团队扩大（如从5人到20人）、需求稳定（如从每周迭代到每月迭代），很多团队会逐步从“单体架构”过渡到“BFF+SOA/微服务”，这正是架构“按需演进”的体现。