建模交互(领域驱动设计)

Question

要使用一个愚蠢的例子，假设特定的用户(劳动者)可以移动箱子。你将如何在你的系统中以一种扩展的语义方式来表示这一点。我目前倾向于做以下工作。

class User {
 // ....

  lift(box: Box) {
    if(this.role === UserRoles.Labourer) {
      box.setPosition(box.xPosition, box.yPosition + 10);
    } else {
      // whatever
    }
  }
}

我正考虑朝这个方向走，因为它捕捉了用户可以lift一个框的语义。但是，由于更改实际上正在发生在盒子上，我们仍然需要一个方法来更改盒子的属性(即创建一个setPosition方法来设置盒子的位置)。你认为这个决定合适吗？你会通过在动词的主语上提供一个方法并在对象上提供相应的方法来模拟这样的交互吗？当我试图以一种表达的方式用代码捕捉我的业务的语义时，我问这个问题，我想知道这是否曾经被想到过。

此外，是否有更好的方法来捕获只有具有Labourer的用户才能执行此操作。把这张支票放在我放的地方好吗？在Box类中做得最好吗？你对此有什么想法吗？

Answer 1

对于耦合用户的域和Box的域，我会非常谨慎。

显然，这只是一个例子，所以你不能说，但似乎在一个DDD系统中，你可能有很多用户参与的事情，不涉及框。

因此，您可以使用接口来松开耦合。

Lift(thing: IMoveable) {...}

或者将位置的概念更改为容器。

IThing
{
   Id: string
   Type: string
}

User : IContainer
{
    Contents: IThing[]
    Lift(thing, currentContainer) {
       currentContainer.Remove(thing)
       this.Contents.Add(thing)
    }
}

Warehouse: IContainer
{
    Contents: IThing[]
}

现在你可以知道事情在哪里了

甚至倒转这个概念，使对象本身不知道它们在哪里。这可能更像是“真正的世俗”

LocationOfThing
{
    Id: string
    Type: string
    position: Vector
}

LocationTracker
{
    Things: LocationOfThing[]
}


User
{
  Lift(thing)
  {
     this.OnLift(thing, this); //locationtracker handles event and updates positions
  }
}

Answer 2

我最初的反应是双重的：

1. 除非对移动框有限制，否则移动框的用户(或劳动者)应该是元数据。充其量，你只需要一个LabourerId。
2. 移动框的约束很可能不是人为的约束。这更有可能是一个业务问题--这就是需要建模的问题。建模业务流程，而不是物理流程。
   • 除非业务流程实际上是物理模拟。

您还没有详细说明有关规则的任何细节，因此以下是纯粹的猜测，但这是一个很好的思考练习。考虑到人类确实有限制。例如，如果你在一个盒子里有一辆套件车(一辆全尺寸的汽车完全拆卸，因为有些汽车爱好者喜欢建造汽车)。一辆打包好的车可以重1-2吨。没有人会捡起它然后移动它。同样，一包纸巾也不会被叉车搬动。考虑为用来移动框的人或事物创建一个抽象。这为您提供了一个获取额外约束的位置，例如重量和大小限制。有些是身体上的限制。有些可能是法律上的限制。一个人可以移动箱子，但是超过一定重量的箱子需要两个人(出于安全和/或法律原因)。叉车需要经过培训并持有执照的操作员。

我意识到我把你简单的例子举到了一个极端，但是你想考虑一下“移动盒子”的真正含义。深入挖掘，找出如何、何时和谁移动盒子的规则。只有了解了这些规则之后，才能创建适当的抽象，其中可能包括具体的类、接口或抽象类。

Answer 3

没有上下文就没有设计，即定义上下文的一组需求。即使你理解商业案例，尝试建模“现实”也是没有意义的。

设计决策是基于需求定义的权衡，而不是“现实”，即使有一些重叠。像“应该解耦”这样的语句在不了解这个上下文的情况下是完全没有意义的。我们不知道这个案子的背景。

我不确定我们在这件事上是否意见一致。DDD中的“有界上下文”术语正试图准确地告诉我们上述情况。我们不是在建模“现实”，而是在建模其中的一小部分，在这个过程中，事情的意义可能与其他环境中的不同，或者对一个只是天真地看待它的外行人来说。

简而言之：“这取决于”:)系统需要表现什么行为，而不管外部的“现实”如何。除了被解除之外，Box还有其他的行为吗？Users还有其他行为吗？我们是否需要分别为“劳工”建模？用户需要一种编程方式来区分角色，还是“只是”一种访问控制机制？

这些事情可能决定了最初是否存在一个Box，或者角色是否需要自己的类型，或者“提升”最适合的位置。