Architecture 在我的特定场景中处理域模型依赖项的最佳方法

我个人学习项目的情景（不是家庭作业）：

许多机器人需要解迷宫。我需要经常打印迷宫 有了机器人，每个机器人都需要知道自己在迷宫中的位置

所以我创建了类Land来定义迷宫墙的x，y和机器人可以行走的空间。显然我需要一个机器人类

但是，我需要知道机器人在陆地中的确切位置（x，y），并且机器人需要查看陆地，以确定它可以走的方向。正如我们所看到的，领域模型具有高度的双边依赖性

可以在两个域模型中都注入依赖项，并且两个域都有很多相互依赖的逻辑吗？例如：Land具有一组机器人，以及机器人移动后通知其在地图中位置的Land对象

或者我需要创建另一个层，并在singles类中接收ILand和IRobot（有名称建议吗？），并在那里生成相互依赖的所有逻辑

有没有最好的解决办法？（请记住，我无法改变情景）

---

我希望有一个没有其他层的解决方案，因为对于这个简单的项目来说，它似乎过于工程化了，服务层不能有很多这样的业务逻辑，我不是在寻找一个贫乏的模型，但是域之间的高度依赖性困扰着我，我想知道这是否合适。

我建议引入一个“障碍”概念来消除双向依赖关系

---

迷宫和障碍物（可能还有墙）在同一个包裹里。因此，Robot依赖于包（与迷宫关联，实现障碍），但反之亦然。

如果您想使用依赖项反转进行解耦，那么它既不是正确的，也不是错误的。你需要做你觉得舒服的事。然而，您可能会遇到这样的场景，即真正需要进行解耦。在给定的场景中，似乎所有这些东西都属于一个整体

如果你最终得到一个类似于迷宫的东西，它可以有各种不同的“居民”，并且你需要它是可扩展的，那么你可以重构成类似于IInhabitant的东西

---

所以，如果你知道你不会有一个固定的结构，而是更具可扩展性的东西，那么你最好还是使用接口。接口也可能有助于测试，并在这样做时突出一些您需要的其他抽象，例如运动。

我们可以暂时忘记我的场景，我想知道“概念”。我应该总是创建一个域模型来处理依赖关系，而不是创建两个相互依赖的域模型吗？我可以用它作为经验法则或最佳实践吗？@Wagner个人认为，在双向依赖关系出现问题之前，我不会进行重构。例如，一段时间后，客户不仅想要机器人，还想要一只功夫熊猫通过迷宫：）