Let's stir up the discussion with a somewhat provocative point of view. It's possible for a mind to create abstractions as beautiful as a crystal castle in the sky, and in many games it would be just as useful.
Personally, I found it quite beneficial for game architectures to "flow from below": first think about data, then about feasible limitations of various kinds, and only after that think about ways of manipulating said data, instead of conjuring up some architecture based on a currently opened page of a book about patterns. That way your code will be structured and effective in a way most optimal for your game and your task. Otherwise it is a potential end in a Procrustean bed of patterns and imaginary data. It's not that bad, especially for an enterprise application with a team of fellow developers on an outsorce basis, maybe even for beginner game developer, but we can do better. For an example on a code organization of a very complex game I would recommend looking at "Jagged Alliance 2" sources. It's definitely not the most beautiful thing in the world, but since it's basically naked functions operating on data, it shows a way of game development from times when patterned thought process wasn't a devotion.
Let's say we're developing a pathfinding for a turn-based strategy. In theory it's possible to make the pathfinding architecture ideal and abstract to the point where we can make a RTS instead of a TBS using the same architecture with ease. Do we need to do that? Pathfinding for a single unit of fixed size in a turn-based tactical game with small fixed map has substantially different data from a pathfinding for a lot of units with different sizes and traversal capabilities in real time strategy with dynamic map of large size. So in reality such approach will yield us a slower pathfinding, which will frustrate gamers, with more entities than needed for an actual task, which will frustrate developers, and only a limited ability to be more agile before it would be needed to rewrite a pathfinding engine. So nope, we don't need to design overly complex interactions to support something illusional unless developing a generic game engine or construction set.
Back to the original monster case. The most obvious, clear and blatantly generic way to express intent of moving a monster would be:
// or oif there is a reason for logic extraction,
It's good for a game where you often move single monsters around by hand, i gueess.
But what if our game is about wasps, and they come in numbers, and if even a single wasp comes somewhere, other needs to be notified to come after him soon? And wasps are actually controlled by evil wasp hiveminds competing for power? Moving a single monster would become like a 1% of all move cases; it's counter-productive to guide every wasp manually, and now moving intent expressed like this:
Then AI engine will check that swarm can move, has scouts, can find path to the position, and create appropriate move behaviour it the to-do list with the highest priority, which will be executed the nearest update, where it fill finally move that single scout one way or the other, it doesn't matter to us much. Needless to say, all movement routines and pathfinding would be optimized for a swarm movement, not for a single unit.
You see in our mind we started with a generic single monster as a main entity, but with the actual game in mind it quickly can become just a small and insignificant part of something greater, basically a set of data for others to operate on.
So the main point is, think about your data, write a design document first, choose your architecture later, and it will be a good choice whether you decide to use naked objects, MVC, PAC, MVP, SOA, event-driven entity systems or not — in your mind you've already won.