【问题标题】:when should assign responsibility to service instead of entity object?什么时候应该将责任分配给服务而不是实体对象?
【发布时间】:2015-01-01 08:27:37
【问题描述】:

是否有任何经验法则规定何时应将责任分配给服务对象而不是实体对象?我真的对此感到困惑。

【问题讨论】:

    标签: oop design-patterns domain-driven-design


    【解决方案1】:

    我认为这里没有经验法则。确定类的职责是设计面向对象软件的技能。

    也就是说,你的班级设计应该会给你一些提示。例如,如果您计划创建一个方法作为实体的一部分,但该方法需要不属于实体的数据,这表明该方法在实体之上的级别上运行,可能是域服务。

    【讨论】:

    • 我需要像您提到的那样的指导:“如果您计划创建一个方法作为实体的一部分,但该方法需要不属于实体的数据,这表明该方法正在运行在实体之上的级别,可能是域服务。”谢谢你。
    • @mohsenkw 您应该阅读蓝皮书或 DDD Quickly 版本。里面都有解释。教科书示例是TransferFunds() 不属于源或目标Account,而是属于FundsTransferService 类。
    • 另外,Vaughn Vernon 最近的书也很棒。当你使用 DDD 分解它时,你要么有一个实体、一个值、一个聚合、一个工厂、一个存储库或一个服务。就类不是什么而言,消除过程有助于确定其角色。
    【解决方案2】:

    据我所知,关于领域驱动设计,实体对象是一些复杂数据的表示。很可能他们没有任何业务逻辑。

    因此,如果您正在考虑仅保存数据的责任,那么它将进入实体对象。服务对象是负责对具有提供上下文的给定值或实体对象执行复杂逻辑的对象。

    【讨论】:

      【解决方案3】:

      当您需要对多个聚合根进行操作时,请使用域服务。

      【讨论】:

        猜你喜欢
        • 2015-08-08
        • 1970-01-01
        • 2012-06-13
        • 1970-01-01
        • 1970-01-01
        • 2023-04-07
        • 1970-01-01
        • 2015-10-29
        • 1970-01-01
        相关资源
        最近更新 更多