You’re absolutely right - the vocabulary of Entity/Component/Worker in SpatialOS was intended to be a distributed-systems extension to the Entity/Component/System architecture that is popular in modern game engines!
One thing we try not to be opinionated on though is whether a Worker has an Entity-Centric Entity/Component architecture (like Unity vanilla, or sort of like Unreal with ActorComponents) vs. a System-Centric Entity/Component/System architecture (like Unity’s new ECS). In the former, the game logic is written inside individual Entities/GameObjects (like putting a MonoBehaviour in a Prefab in Unity). With the latter, the code sits outside of any concrete Entity, instead having Systems iterating through groups of Components of the same type.
Our Worker API happily supports both Entity-Centric or System-Centric Workers. We’ve even thought about different types of Worker within a single project having different programming models depending on the type of work! AI could hypothetically benefit from more Entity-Centric programming, but Physics may benefit from being more System-Centric.
Unity has always matched pretty well onto SpatialOS due to its GameObjects and Components mapping relatively well onto SpatialOS’s Entities and Components. However, our Unity GDK team has also been very excited recently by Unity’s ECS too - the idea of a System matches quite well onto the idea of a Worker (although in practice a Worker may have many Systems inside of it!). Things like sending commands in SpatialOS seem Entity-centric at first, but you are in fact sending an RPC to the Worker that is currently simulating that Component.