Hi, thats a big question, and the best approach really depends on many things within your game. For example, if you have millions of entities, many of which are not visible at any one time, then you probably only want to create their graphical representations when they come into view, so a 1-to-1 graphics entity to game entity may not be appropriate.
Personally I would start off with a single graphics class/module that communicates with the Playfield, as you mentioned. That way you can change up its internals as you develop further. As the requirements change (and they will!) you might need to spatially partition the graphics objects for quicker collision detection, rendering, picking, etc ..
I really have no idea about your game, but for instance, if your AI controller adds a new enemy to a game, you might have some logic like..
// aiController
void decision(){
...
playField.addEntity(ENEMY,...);
}
// playField
void addEntity(...){
...
graphicsSystem.entityAdded(...); // might load and create the sf::Sprite and add it to an internal tree of some sort
physicsSystem.entityAdded(...); // e.g., might create a box2d body
}
In this case playField is acting like a main controller AND model, who knows about the other systems.
When some input comes in, e.g., a mouse click, your main system would first pass it to the UI layer, then might ask graphicsSystem (or physicsSystem) if the click intersects an entity. If so, you might then ...
playField.entitySelected(...);
which would then tell the graphics system in order to provide a highlighted rectangle around the object etc..
HTH