【问题标题】:How AggregateRoots aggregate diffident object types?AggregateRoots 如何聚合不同的对象类型?
【发布时间】:2017-09-06 20:23:31
【问题描述】:

假设我们将 Foo 作为 AggregateRoot。并且有通用的 Foos 以及具有许多扩展属性的 EnhancedFoos。如果在非增强 Foo 对象上调用增强操作,是否可以在单个聚合根类上为通用和增强属性公开“操作”并进行验证检查以引发异常?从技术上讲,这种情况下的 AggregateRoot 将为所有支持的 Foo 类型聚合所有可能的“Actions”?

显然很大程度上取决于域结构,但我认为这种假设情况很常见。可能是基本问题,但我只是从聚合/根开始。

根据反馈更新

假设我们将 Foo 作为 AggregateRoot。并且有通用的 Foos 以及 FlyableFoos、SwimmableFoos 等。所以,Aggregate 应该“了解”所有可能的行为(飞行、嘎嘎、游泳)并将其适当地暴露给服务功能。如果某事被当前对象“不支持”的某些原因调用,Aggregate 可能会抛出异常“对不起,企鹅不能飞”。

【问题讨论】:

    标签: design-patterns domain-driven-design cqrs aggregateroot


    【解决方案1】:

    我认为这不是一个好主意。在使用 DDD 方法的同时,您应该尝试保持干净的代码。因此,我建议您在编码聚合时尊重SOLID 原则并尝试favor composition over inheritance

    另外,在设计聚合时,您不应该考虑properties,而是考虑状态和行为。这在 CQRS 中更重要,因为您不查询聚合,您没有任何 getter(根据 DDD,您没有任何 setter,您应该根据普遍存在的语言命名您的方法)。

    您可以使用继承,但您必须确保获得(代码重用)大于您失去的(增加的认知努力)。不推荐。

    如果某事被当前对象“不支持”的某些原因调用,Aggregate 可能会抛出异常“对不起,企鹅不能飞”。

    这会破坏Liskov substitution principle

    【讨论】:

    • 我的问题并不清楚,但我确实使用了组合。另外,我应该说“属性”,而应该说“行为”。我为我的问题添加了更新,请检查。另外,感谢您提到“组合优于继承”图,非常有帮助!
    猜你喜欢
    • 2021-07-28
    • 1970-01-01
    • 2021-10-13
    • 2019-07-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-08-25
    相关资源
    最近更新 更多