为什么那些乏味的决策反而是我做出的最佳决策
我以前认为，成为一名优秀的开发者意味着编写复杂的代码。
我错了。
在为一家最终将发展为多租户 SaaS 的医疗诊所设计 MVP 时，我吸取了一个深刻的教训。编写代码是容易的部分，难的部分在于决定“不”构建什么。
我曾面临使用微服务、事件驱动和 Kubernetes 的诱惑。这在简历上看起来很漂亮，但微服务是有高昂代价的。你必须为之付出复杂的流水线、版本控制问题以及难以调试的代价。
对于一个只有三个人且用户量较少的团队来说，微服务只会增加额外的工作量。你是在解决那些目前还不存在的问题。
相反，我选择了一个基于 .NET 8 和 PostgreSQL 的简单分层架构。每月成本大约只需 30 美元。
我专注于那些现在成本低廉、但以后修改成本极高的明智决策：
• 从第一天起就在每个表中添加了 TenantId 列。
• 从第一次提交起就使用了 Docker。
• 为 WhatsApp 提供商创建了一个接口。
这些工作每项只需一个下午。它们将未来的迁移变成了简单的配置更改。
我还学会了根据业务需求来权衡设计模式。
例如，我针对 WhatsApp 通知使用了 Outbox 模式。预约挂号必须快速且可靠，而发送消息可以在两秒后进行。即使 WhatsApp 响应缓慢，预约流程依然可以正常运行。
然而，对于医疗记录，我拒绝使用“最终一致性”。医疗诊断必须准确且即时。在医疗保健领域，法律要求实际上就是架构要求。
我还计算了实际的账目。
一套 Kubernetes 设置 (EKS) 每月将花费 545 到 615 美元。 一套 AWS Fargate 设置每月仅需 350 到 420 美元。
这意味着每个月可以节省超过 150 美元。我选择 Fargate 是因为它在目前的规模下更简单、更便宜。
我的策略很简单：
- 首先使用分层架构。
- 当外部依赖项（如 WhatsApp）开始影响你的系统时，再使用事件驱动。
- 只有当业务量和团队规模确实需要时，才转向微服务。
不要为那二十个尚未到来的客户进行设计。要为今天正在为你付费的客户进行构建。