Best way to work with Domain Model dependencies in my specific scenario

Question

My scenario for a personal study project (not homework):

Many robots needs to solve a maze. I need to print the maze constantly with the robots, and each robot needs to know where it is in the maze

So I created class Land to define x,y of maze walls and spaces where robots can walk. And obviously I need to have the class Robot.

However, I need to know the exactly location (x,y) of Robot in the Land, and Robot needs see Land, to define which direction it can goes. As we can see, the domain models have a high bilateral dependency.

1. Is okay to inject dependency in both domain models, and both domain has a lot of logic that depends of each other? eg.: Land having a array of Robot, and Robot the Land object to inform where it is in the map after a move.

2. Or do I need to create another layer, and receive ILand and IRobot and in a singles class (any name suggestion?), and make all logic that depends on each other there?

3. There are a best solution for this? (Remember that I can't change scenario)

I wish to have a solution without other layers, because it seems to be over-engineering to this simple project, and a Service layer cannot have a lot of business logic like this, and I'm not searching for an anemic model, but these high dependencies between domains is bothering me, I want to know if this is OK.

Answer 1

If you want to use dependency inversion for decoupling then it is neither right nor wrong. You need to do what you are comfortable with. However, you will probably run into scenarios where the decoupling is a real necessity. In the given scenario it seems rather like all these things belong together.

If you end up with something like a Maze that can have various different 'inhabitants' and you need that to be extensible then you could refactor to something like a IInhabitant.

So if you know that you are not going to have a fixed structure but rather something more extensible then you may be better off going with the interfaces. Interfaces may also aid in testing and in doing so highlight some other abstractions you require, e.g. movement.

Answer 2

I'd suggest to introduce a concept "Obstacle" to eliminate the bidirectional dependencies.

The Maze and Obstacle (and maybe the Wall) are in the same package. Therefore, Robot depends on the package(associates with Maze, implements Obstacle) but not vice versa.