Judging by what @davidluzgouveia commented on annonymously's post, I'll bring up my project. Path following and path finding are very different though. Path finding is more of what annonymously was posting about, and for path finding I would look into Dijkstra's algorithm. For path following I use my choice physics engine entirely. The way I have it set up is that each location a unit class walks to, is set up in it's pathing subclass via 2D offsets, yes they are 2D and not 3D this is because of the way I have my physics set up in my game.
3D explaination:
Each unit has only one main collider that is exclusively set up for collision with the terrain and world objects. It's a capsule shape and has a radius, and height programatically speaking. It's built at the center of the model and should extend just past the front and top of the model. But I also have a surface offset for how far it is off the ground at all times, and a float of how much it's allowed to slide down before bouncing up slightly, at a time. This sounds like I'm applying some sort of screwed up fix for a terrain collision problem, but I have my reasons.
Anyways, you should apply force to this capsule object, and it should remain hovering above the ground at all times. That's not to say it can't go any higher, just that it can't go any lower. The reason why it needs to hover (in my case) is because in a rigid body and ragdoll physics engine, the legs of my units are procedurally animated. So by applying a simple force to the capsule, the legs of my entity will reposition themselves on their own. They will also have their separate gravity applications! What this does is allows that if my character is on a slant, one foot can be at a lower elevation than the other.
This is exactly how you should do it. Judging by what you're asking that is. If you want to leave out some features, that's obviously fine, especially if it's an RTS or FPS and no one will ever see units feet or care anyways. But in general, the unit should have one MAIN collision object that works with movement of the character almost exclusively.
Specifically 2D:
You still should have a main point, or just some sort of reference, for the engine to push around that is for the movement of a unit. You could give each unit a pathing subclass that has a few locations it needs to go, you could specify it in the level code, (e.g. location1(x,y) location2(x,y) etc.) the best way (I don't know what kind of game you're working on) would probably be to specify locations in the level and have that each unit will process them in order specified by the level and after it reaches each location, have it replace it's desired location with the next one it needs to get to.
There are tons of ways you could modify that, like having a list of locations in the first place for each unit, since this would mean not all units have to go to the same locations. However, as the same way, you could do this in the level code as well ( unit1.location1(x,y) unit1.location2(x,y) grunt.l1(x,y) knight.loc3(x,y) whatever)
Just a few ideas! I suggest you read the 3D version even though it's far less relevant.
EDIT: I decided to just supply both for anyone who might read this (Yea that's true).... (I originally only skimmed your question and didn't realize it was pretty 2D specific till I reread it >.>)