前端领域驱动设计的一些思考
内容提要
本文介绍了前端业务复杂度的来源和采用领域驱动设计（DDD）的方法来组织前端代码。同时，介绍了两种架构设计方案，分别是通过ViewModel和直接依赖关系来管理视图层和模型层之间的接口。最后，强调了在选择方案时需要考虑业务场景的差异，并全面评估和判断好方案。
关键要点
-
领域驱动设计（DDD）是一种面向对象的软件设计方法，旨在将核心业务领域抽象出来。
-
DDD 主要解决业务逻辑的复杂性，通常这些逻辑在后端实现。
-
大部分情况下，复杂的业务逻辑不在前端，因此 DDD 不适合前端业务。
-
前端通常被视为低层级的细节，易变性较高，技术栈的更替相对容易。
-
细节是实现原则的方式，而策略是编写代码时遵循的规则和原则。
-
高层级策略是应用程序的核心业务逻辑，通常不易改变。
-
将高层策略放在后端可以确保规则的统一执行，前端专注于展示和交互。
-
前端的稳定性较差，UI 组件的实现受业务需求影响，导致代码差异化。
-
前端开发中，修改功能时通常需要直接修改代码，违反开闭原则。
-
前端业务复杂度包括技术栈复杂度、业务逻辑复杂度和 UI 交互复杂度。
-
技术栈复杂度体现在组件组织、状态管理和异步数据处理等方面。
-
业务逻辑复杂度源于业务需求，缺乏清晰划分会导致代码难以维护。
-
UI 交互复杂度涉及复杂交互逻辑、动画效果和用户反馈处理。
-
降低前端复杂度的方法包括借助领域驱动设计的思想进行实践。
-
领域模型是具有业务含义的类或对象，封装关键业务逻辑。
-
状态管理分为业务模型层和视图层的状态管理。
-
视图层是最不稳定的一层，需遵循稳定依赖原则。
-
架构分层是解决复杂性问题的重要原则，需明确每层的角色和任务。
-
方案一通过 ViewModel 管理视图层与模型层的接口，方案二则是直接依赖关系。
-
在选择方案时需考虑业务场景的差异，避免过度设计。
-
开发者需站在领域模型层为中心进行系统设计，并理解业务领域模型。
