What Defines a Day?
程序员在构建新功能时，往往关注错了重点。
你可能会考虑后端数据、代码重复或性能。这些问题很重要，但它们并不是最重要的。
我经常犯这个错误。我会沉迷于巧妙的设计模式和整洁的代码，在还没完全理解用户如何使用功能之前就开始写代码。然后我才意识到，我的代码与业务目标并不匹配。
以日历应用为例。
用户点击 3 月 1 日来标记一个节假日，但应用却标记成了 2 月 28 日。这种情况的发生是因为时区问题。
开发者使用了 Date 对象。Date 对象代表的是时间轴上的一个特定瞬间。
在东京，3 月 1 日的午夜，伦敦还是 2 月 28 日。如果你的代码使用 UTC 方法来保存日期，日期就会发生偏移。
这个 Bug 的存在，是因为技术实现与业务逻辑相冲突。
用户是以“天”为单位来思考的。用户不会去考虑 UTC 偏移量或毫秒级时间戳。他们想的是：“我要 3 月 14 日。”
如果你希望代码是可靠的，你必须正确地进行领域建模。
在纸质日历中，日期仅仅是年、月、日。它没有时区。
你可以通过保持与 UTC 或本地时间一致来修复这个 Bug。但这只是治标不治本。更好的方法是使用不会出错的数据结构。
不要使用 Date 对象，而是使用自定义对象：
• 年：2026 • 月：3 月 • 日：1
这从方程式中剔除了时间和时区。这让 Bug 变得不再可能发生。
是的，这需要更多的工作。你必须编写工具函数来比较日期或查找月份的最后一天。你还有截止日期和 Sprint 需要操心。
但正确地进行领域建模，可以让你免于日后处理愤怒的客户支持工单和数小时的调试工作。
正如 Eric Evans 在《领域驱动设计》（Domain-Driven Design）中所说：
"To communicate effectively, the code must be based on the same language used to write the requirements."
不要只站在程序员的角度思考。开始思考业务规则吧。