从MVP到生产：像做产品一样构建小型业务平台
本文译自 dev.to 文章《From MVP to Production: Building a Small Business Platform Like a Real Product》，作者以一家光学实验室的小型业务平台为例，讲述如何在不过度设计的前提下完成架构设计、开发与部署。原文链接见文末。
导语
一位开发者将内部业务构想从开放式问题推进到可供真实业务日常依赖的生产级 MVP。目标不是搭建最大或最复杂的架构，而是划清边界，让系统能够在不推倒重来的前提下演进为更大的产品。
核心结论
作者用一句话概括了这次实践的核心经验：MVP 可以范围很小，但架构不应是一次性的。
技术栈相当常规：Vue 3 + Vite 前端、ASP.NET Core / .NET 10 后端、PostgreSQL 持久化、Entity Framework Core 数据访问、Docker 打包、Nginx 反向代理、Playwright 端到端验证、FluentValidation 请求校验，初期托管在 DigitalOcean。
真正重要的决策不是选了哪些技术，而是决定不引入什么：没有 Kubernetes、没有消息代理、没有微服务拆分，也没有为了架构图好看而堆砌的复杂云拓扑。
从约束出发，而非从技术出发
应用形态本身很直接：浏览器界面、后端 API、关系型持久化、认证，以及少量支撑性基础设施。由此自然得出常规技术栈。作者强调的原则是：
使用能够保留产品未来可能需要选项的最简架构。
这与"尽可能简单地搭个东西"有本质区别。
刻意"无聊"的架构
整体架构为：用户经 HTTPS 访问 Vue 应用，Vue 通过 REST API 调用 ASP.NET Core 后端，后端访问 PostgreSQL。三层职责清晰——Web 应用负责用户体验，API 负责应用行为与安全边界，数据库负责持久化与关系完整性。这些职责可以独立演进，而无需让整个系统变成分布式。
按能力组织代码
后端采用面向特性的组织方式，把 Clean/Onion Architecture 当作原则而非必须逐条照搬的清单。应用按能力划分，而非按技术分层：
Application
├── Authentication
├── Catalog
├── Workflows
└── ...作者指出，业务应用通常按能力变化——需求很少以"请修改持久化层"的形式出现，而是"这个工作流需要换个行为"。架构应让这类变更易于推理。同时，作者刻意避免为了架构图好看而把每个边界都抽象化，也没有因为用了 Onion 风格就顺手引入 CQRS。
用权衡做技术选型
文章讨论了 GraphQL 与 OData 等 API 方案。两者都是合理技术，但引入额外的查询抽象会给前端、后端、授权模型、测试策略和长期维护带来更多概念。问题不是"哪个技术更强"，而是"我们要解决什么问题，值得付出这些额外复杂度"。对当前产品而言，常规 REST API 已经足够。
| 决策 | 方向 | 主要考量 |
|---|---|---|
| 后端 | ASP.NET Core | 平台支持强、生态成熟 |
| 前端 | Vue 3 | 高效的 SPA 开发与清晰的组件模型 |
| UI 组件 | Vuetify | 统一 UI，无需从零构建 |
| 数据库 | PostgreSQL | 关系能力强、可移植 |
| 数据访问 | EF Core | 高效的 .NET 关系型开发 |
| 架构 | Clean/Onion + 面向特性 | 有边界但不过度仪式化 |
| API 风格 | REST | 满足当前需求 |
| 打包 | Docker | 环境与部署可重复 |
| 托管 | DigitalOcean | 适合 MVP 的简单运维模型 |
| 反向代理 | Nginx | 清晰的 HTTP/HTTPS 入口 |
| E2E 测试 | Playwright | 从用户视角验证关键行为 |
认证是系统边界，不是 UI 功能
认证被当作横切架构关注点处理。前端控制用户看到什么、能做什么交互，但后端仍实现第二层授权。这既保证安全——API 必须独立于 UI 暴露内容执行授权规则——也让授权模型不与当前前端紧耦合。今天 API 的消费方是 Vue 应用，但未来若换成 React 或被其他应用消费，同一套授权规则应继续适用。
数据库为产品而设计
持久化层使用 PostgreSQL 与关系模型，没有因为"应用可能长大"就引入第二种数据库。数据库围绕领域中有意义的关系与不变量设计，同时让持久化模型对应用核心而言是可替换的实现细节。作者强调，MVP 同样受益于良好的数据完整性——预防非法状态远比在生产数据积累数月后再发现要便宜。
从用户视角测试
自动化测试应验证行为而非实现细节。单元与 API 级测试有用，但回答不了最重要的问题：真实用户能否完成工作流？这正是 Playwright 的价值所在。测试策略覆盖多个层次：领域/应用逻辑对应单元与集成测试，API 行为，再到端到端场景，最终形成生产信心。端到端测试不是低层测试的替代品，而是回答"各部分是否真正协同工作"的最后一层。
从应用到系统
问题最终不再只是应用代码，而是可部署性。基础设施架构同样受产品经济性影响：预算、运维复杂度、云资源、工程时间都有成本。作者希望同时回答三个问题：什么基础设施符合预算与能力？能否以很少的持续技术干预支撑产品？出问题时诊断修复需要多少时间与专业能力？
答案是一个 DigitalOcean droplet，应用组件拆分为容器。Nginx 提供公网 HTTP/HTTPS 入口，域名通过 Porkbun 管理，TLS 在应用环境边缘终止。作者强调这是当前的架构决策，而非永久承诺——若规模或可用性要求变化，架构可以随之改变。
环境隔离与健康检查
项目需要区分开发、UAT 与生产环境。一个小的环境视觉标识加上应用版本/构建信息，能消除大量运维歧义。原则是：环境应当能自我标识。
健康端点则体现了应用向基础设施关注点的延伸。API 暴露一个匿名健康端点，回答应用进程是否健康到足以被基础设施视为存活。它刻意独立于数据库或邮件服务等外部依赖——存活检查不应变成复杂的业务诊断端点。
仓库也是架构的一部分
仓库不只是存放源码的地方，而是贡献者理解、构建、测试和运维系统的唯一事实来源。架构决策、开发计划、部署配置、容器定义、持久化定义与参考数据、环境模板、基础设施脚本、应用代码和自动化测试都放在版本控制之下。这让项目更易交接——贡献者不必从对话中重建架构决策，或靠试错发现部署约定。
结语
这篇文章的价值不在于技术选型本身，而在于决策模型：用最简单的架构保留产品可能需要的选项，让架构成为变更的促进者，而不是另一层复杂度。