读：Immutability 不是万能药，它是一种权衡
原文中文，约6100字，阅读约需15分钟。
📝
内容提要
不可变性是指数据创建后不再修改，常被视为函数式编程的原则。作者认为不可变性并非普适法则，而是需根据场景权衡的选择。在代码层面，不可变性有助于理解和测试；在数据建模层面，需要考虑状态模型与事件模型的选择；在API层面，则需根据业务复杂度决定使用Command或Event风格。因此，不可变性应根据具体情况灵活应用。
🔎
延伸解读
不可变性的优势与局限
不可变性在代码层面提供了显著的优势，如减少副作用和提高可测试性。然而，在数据建模和API设计中，选择不可变性需要权衡存储成本和设计复杂度。开发者应根据具体场景灵活应用，不可盲目追求不可变性。
状态模型与事件模型的选择
在数据层，状态模型和事件模型各有优缺点。状态模型简单易用，但无法追踪历史变更；事件模型则提供完整的历史记录，但存储和设计复杂度较高。开发者需根据业务需求和数据重要性做出合理选择。
API设计中的Command与Event
在API层面，Command风格强调意图，而Event风格则记录事实。复杂业务逻辑适合使用Command/Event风格，而简单的CRUD应用则可直接使用状态表示。选择合适的风格可以提高系统的可维护性和可扩展性。
❓
Q&A
不可变性在编程中有什么优势？
不可变性有助于理解和测试代码，避免隐藏副作用，提升并发安全性。
在数据建模中，状态模型和事件模型有什么区别？
状态模型只存当前值，而事件模型记录每一笔变更，提供完整的历史信息。
在什么情况下应该使用事件模型？
应在跨系统共享状态、历史有业务价值或需要回溯查询时使用事件模型。
API层面上，Command风格和Event风格有什么不同？
Command风格表达意图，Event风格记录事实，前者请求操作，后者确认发生的事件。
不可变性在代码层面是否总是推荐使用？
在代码层面，不可变性基本上是强烈推荐的，因为代价小而收益大。
使用不可变性有什么潜在的缺点？
使用不可变性可能导致存储成本增加和设计复杂度上升，特别是在数据层和API层。
🏷️
