This is a follow-up question of Split Contract Design Pitfall
Background: I have split my logic into two contracts A and B. A keeps the state and not ETH. All state change functions are only allowed to come from its owner, contract B. Contract B functions interface with public (and are payable).
Everything works now. However, as business logic grows, the state contract A is literally on the edge of running out of gas during deployment -- i.e., at 8M gasLimit, it only deploys if solc optimizer runs <= 1000, any optimization higher than that will fail the deployment out-of-gas -- which means I can not add even a one-line function in contract A.
My question is: Is there a way to further split state contract while my state struct/mapping/array are pretty closely related to each other. Is there a design pattern that achieves separating states into multiple contracts yet still allow them to interact with each other?
How about the setter functions? Is there a way to separate the setter functions out yet allow them to set their state variable?
Or are there other smart ways that I'm not aware of?