The "pure aggregation" approach described by West in that linked article eschews an "entity" object altogether. There are components, floating around in memory, but they are tied together only by implicit relationships, if at all.
One way to do this is a so-called outboard approach. In such a system, components are held by systems that manage or otherwise control them (I use the term "manage" here, but you shouldn't take this to mean I'm suggesting that you have a bunch of *Manager classes to hold component types). For example, your physics system may hold on to a bunch of things representing each rigid body in its simulation world, and may expose those things as PhysicsComponents. The components can be the actual objects handled by the subsystem in question, or they can be proxies for those objects, as needed.
In such a system there isn't necessarily a need for an "Entity" class to hold a collection of references to the components that comprise it; instead a notification is raised concerning the creation or destruction of an "entity" and each subsystem that handles components looks at the description of the created/destroyed entity (which is typically loaded from some data) and determines if a component is necessary for it.
One of the advantages to this approach is that you get really good locality of reference for each component. Unfortunately it's a bit weird, overall, and not the most friendly flavor of component-based entities I've encountered. Sometimes it is really convenient to have a real object that represents an entity, even if that object does little more then aggregate weak references to components that are still held by other subsystems (if nothing else it provides a easy way to route messages between components).
There are several good ways to implement component oriented game object systems; it really, really, really helps if you have a solid idea of the requirements you want out of your system -- you can look at what popular frameworks like Unity do for examples. Without setting strict requirements for yourself, you may run into the problem of endlessly "designing" the system without ever really building it, trying in vain to hit upon the perfect implementation. For whatever reason I've seen this a lot with component systems.