不应在 DDD 中使用 Prototype Extension，因其导致全局污染、语义失真、模型不可控及阻碍限界上下文隔离；应改用类/工厂建模、领域服务、值对象和仓储等显式、受控的 DDD 实践。
Prototype Extension 本身不是 DDD 的组成部分，也不推荐用于实现 DDD。DDD 的核心是业务建模与分层架构，而非修改原生对象（如 Array.prototype 或 Object.prototype）来注入行为。
为什么不应在 DDD 中使用 Prototype Extension
领域驱动设计强调清晰的边界、可预测的行为和可测试性。而向原生原型链添加方法会带来以下风险：
-
全局污染：修改
Array.prototype等会影响所有代码，包括第三方库，极易引发隐蔽冲突 -
语义失真：例如给
Array.prototype.calculateTotal()添加订单金额计算逻辑，违背数组的通用语义，破坏“单一职责”原则 -
模型不可控：DDD 要求领域对象（如
Order、Product）封装自身规则和生命周期，而原型扩展无法绑定到特定领域类型，也无法表达聚合根、值对象等关键概念 - 阻碍限界上下文隔离：不同上下文（如订单管理、库存管理）可能对同一术语（如 “available”）有不同定义，原型扩展无法支持上下文专属语义
DDD 应该用什么替代 Prototype Extension
DDD 鼓励显式、受控、可演化的领域建模方式。推荐以下更安全、更符合 DDD 原则的做法：
-
使用类或工厂构造领域对象：例如
class Order { constructor(items) { this.items = items; } get total() { return this.items.reduce(...); } }—— 行为归属明确，生命周期可控 -
将跨领域逻辑封装为领域服务：如
OrderValidationService.validate(order)，避免把校验逻辑散落在原型上 -
用值对象封装不变业务概念：如
Money、Address，通过构造函数确保合法性，而不是靠扩展String.prototype来“增强”字符串 - 借助仓储（Repository）和工厂（Factory）解耦创建与使用：让对象实例化过程体现业务意图，而非依赖隐式原型行为
如果已有原型扩展代码，如何平滑迁移至 DDD 风格
可采用渐进式重构策略，不追求一步到位：
- 识别被扩展的原生类型实际承载的业务含义（例如
Array.prototype.asOrderItems()实际是“一组订单行项”），为其创建专用值对象OrderItemList - 将原型上的方法逐一提取为领域对象的方法或领域服务函数，并添加单元测试验证业务规则
- 在构建工具中启用 ESLint 规则（如
no-extend-native）阻止新增原型扩展 - 利用 TypeScript 接口 + 类型守卫，代替运行时对原生类型的“打补丁”式增强
DDD 不是语法技巧的集合，而是业务理解落地的过程。放弃原型扩展，转而用明确的类型、受限的边界和协作的语言建模，才是贴近领域本质的做法。
