Understanding of schema and tablespaces - recommendation for a later seperation
I think you are over complicating this.  Grants and roles govern access by users not what table space and data files where the data is located in.  Yes, backup, recover and export are much easier if schemas have their own table space but that doesn't seem to be your question.  


Separate your business domains by user/schema.
Give each user/schema their own group of tablespaces which contains their tables/indexes/lobs eg: User1Data, User1Indexes, User1LOBS
create roles to allow users/schemas to access data/code in other schemas


From your comment below I would add:


user/schema are the logical way to separate data and code.  Use different schemas from day one if your business domain works that way (and that seems to be what you are indicating).  Moving tables to different schemas after deployment can be done but it's a pain.
in your comment you still link table spaces and permissions.  There is no link between what table space a user's data is in and the permissions granted on that data.


If you will allow me a simplification:


users and schemas allow  you to control access to data and code through roles and grants
table spaces and data files allow you to manage the physical files used by the database.  Easier backup and recovery are one of the things that is easier to do when each user has their data in a clearly defined set of table spaces.