I typically try and avoid bidirectional relationships at all costs.  Recently I've been trying to follow a more domain centric design philosophy and I'm looking for advice in the best way to solve a specific problem.I am implementing a basic 2d grid.  There are 3 basic classes, Item, Tile (has a list of Items), and World (has a 2d array of Tiles).I am struggling with where to put the move() method which moves an item from one tile to a neighboring tile.  My initial inclination would be to place the move method in the Item class since it is the item that is actually moving.However, that would create a circular dependency.  In the past I always worked with dumb objects in which case the move() method was in a higher layer (some kind of WorldManager or MoveManager) which knows about both tiles and items. I'm interested in what proposals others might have that can avoid the circular dependency while maintaining the domain-centric philosophy.
Justification for bidirectional relationship
domain driven design;domain model;dependency analysis
To answer your question directly:A player would tell (by picking it up) an item to move from one tile to another. So logically, the move method goes on Item and receives the two Tiles as parameters.Now having said that:Don't let DDD get in the way of single-responsibility principle. It's ok to have non-entity items, such as MoveManager, and call it part of your domain. Just because you don't persist it anywhere, doesn't make it less a part of the domain.People often confuse the data model with the behaviour (or business domain) model when talking about DDD. Anything can be an entity. In fact, one could argue that anything persisted already has its single responsibility and shouldn't be given any more.From MSDN:I, for one, am not disturbed by the need to involve other, non-entity classes, and I would try to avoid lifting the central behavior outside of my entity. You should always remember that entities are intrinsically behavioral units. Often that behavior will be implemented as a kind of state machinewhen you invoke a command on an entity, it is responsible for changing its internal statebut sometimes it's necessary for you to obtain additional data or impose side-effects upon the outside world.