掌控技术栈，为客户提供真正的增值

Source: Dev.to

第 1 部分 — 拥有技术栈从业务域开始

（这篇文章有点长，我把它拆成了 3 部分）

很多所谓的“定制化”其实只是对 UI 边缘的微调。项目往往注定失败，你只是在泰坦尼克号上重新摆放甲板椅。要真正实现定制化——并为客户创造价值——必须深入技术栈的核心，真正的价值所在的地方，并进一步深入以获得完整的控制权。

软件栈（分层视图）

1. 基础设施层 – 数据、托管、集成
2. 平台层 – 将模型转化为系统的加速器
3. 业务域层 – 业务模型和规则
4. 应用层 – 工作流、流程、编排
5. 体验层 – 定制 UI、仪表盘、API

如果你为客户或内部团队构建软件，可能已经看到这种模式：

• UI 每年都会变化
• 技术栈每隔几年就会更换
• 业务规则却似乎永远存在

大多数系统的构建方式把业务域当作事后才考虑的东西。

为什么业务域层重要

业务域层才是真正重要的部分。它才是决定客户价值的关键，也是你能够提供最大附加价值的地方。

业务域层包括：

• 业务概念
• 规则与约束
• 政策与不变量
• 数据的含义

这正是你与客户一起站在白板前，定义其业务上下文，并使用他们真正关心的术语进行讨论的地方。它是系统中唯一能够：

• 经受重写而不受影响
• 超越框架的寿命
• 决定软件是否正确的部分

如果你的业务域：

• 分散在控制器中
• 硬编码在 UI 流程里
• 隐式体现在数据库模式中
• 被锁定在某供应商的数据模型里

……那么你根本没有真正拥有系统。你只是在维护一种恰好现在能用的形态。

拥有业务域

拥有业务域意味着你可以：

• 改变 UI 而不改变其含义
• 更换基础设施而无需重写业务逻辑
• 添加工作流而不破坏核心规则
• 用业务语言而非代码路径解释系统

换句话说：**业务域就是客户的真实知识产权（IP）。**如果你不拥有这一层，你并不是在构建系统，而只是在对已有系统进行定制。其他一切都只是交付的机械操作。

拥有技术栈的第一步

在考虑工具、平台或框架之前，先让业务域 明确、连贯且独立。业务域层应当能够超越框架、UI 重写和基础设施的变化而存续。如果它是明确、干净且独立的，你的系统就可以在不失去核心精神的前提下演进。否则，你往往只差一次“大重构”就会意外导致重写和规则破坏。

问题： 你的业务逻辑现在到底在哪里——干净地位于业务域层，还是散落在控制器、UI 流程和数据库模式中？

下一部分（第 2 部）：要在业务域层为客户带来真正的价值，你需要掌控关键的开发环节——平台层——这才是实现真正杠杆作用的所在。