I think that the source of your confusion due to the fact that you mixing the application logic with the business contracts logic which is usually implemented in chaincode.
Say you would like to establish Fabric network among 4 different parties and you need to define a rule which defines how you will split/distributed the asset among those participants. Now, let's put aside the peers. In your chaincode you encode notion of the asset and probably the notion of the users to avoid confusion let's call them persons. So you have 4 persons: Alice, Bob, Charlie and John and business rule which says that once Alice submit an asset it has to be distributed according to 40%, 30%, 20% and 10% respectively.
Next, to continue with say Alice works at Org1, Bob at Org2, Charlie at Org3 and John from Org4. Now you can implement a chaincode which will apply business rule based on whoever submits the transaction. Moreover you can implement ACL based on the submitter identity, hence to prevent from Bob query for balance of the let's say John.
The legitimate question will be why do I need 4 peers to implement such simple logic. As you can have only one peer with chaincode deployed, channel which configured for all 4 orgs and all you need is to send transactions proposal to invoke the chaincode.
The caveat in this approach is pretty obvious you need to decide which org will host and run this peer and the chaincode, therefore as all 4 orgs doesn't really trust each other they would like to host they own peer and invoke chaincode against theirs own peers. And in order to prevent each org to trick each other and reduce the influence of adversarial/non-deterministic behavior they will agree on endorsement policies which actually will make sure that peers of other orgs also receives same results as you during the simulation.
Now back to your question, peers are used to simulate transaction against current state and sign on the results, send results back to the client which aggregates endorsements based on policies and submits results to the ordering service which cuts blocks and deliver them to the peers, which will validate correctness of transactions in the block and eventually commit them to the ledger updating state.
Therefore your chaincode should encode notion of clients/users/persons among which you will distribute assets, those users could be mapped back to the client application (real world users), which might be enrolled into different organizations, hence having different certificates signed by appropriate org CA. Finally you will be able to leverage GetCreator API of the chaincode to understand which client invoked the chaincode and apply business logic and access control based on business logic you defined.
Sorry for making my answer too long, but to summarize. Your application/service will be based on two tiers: first one is the application tier - mapped to the user of org, second tier is the peer which holds the ledger and deployed chaincode - to simulate and execute transactions. Hence you will have 4 peers and 4 clients which will submit transaction to the peers and your logic will be based on the client identities rather on the peers.
Hope my explanation will make sense to you ;)
