Should there be separate smart contracts with same business logic and different configuration or one master smart contract with all the configuration

Question

Let's suppose I've a contract between two parties which allows some money (initially with me) to be transferred to both the parties based on some business logic like 80% money to A, 20% of money to B. Now these percentages are different for a different party pair X & Y. I'll create a smart contract with this configuration and will have a function let's say splitMoney() which will return the two amount values. Now for different party pairs should I maintain an array of such configurations with one master smart contract or create separate contracts for different party pairs. Ideally in real world these are separate contracts but I'm not sure how this models in ethereum blockchain. Would really help if someone could advise on this.

Answer 1

Architectural questions like these are difficult to answer as there is much more that goes into these decisions and the information provided is very limited. The path to take is going to depend on the complexity of the business logic you need to implement, the risk of the amount of money held in the contract, the frequency/volume of the contracts between your parties, your operational budget, and your expected margins. To take some extreme examples, if I were in the business of putting a home buying escrow onto the blockchain, I would make each deal it's own contract (even though the terms of different deals may be similar). If I were building a lottery contract that executed every day, I would put a master contract for all lotteries on the blockchain. In another example, if I were to build a gambling business that supported multiple game types, I may have one master contract that tracks all activity and then delegates to a game specific contract.

All of that being said, I have faced similar situations in my own projects. I would usually start with individual contracts, but found this typically is not cost effective. Contract deployments are very expensive operations and most of my use cases were not like the "buying a house" example. I would end up rolling up my individual contracts into a struct and have one master contract. From the limited information you've provided, you may be falling into this same sort of scenario. But, again, it's hard to give a definitive answer without having a set of business requirements in front of me. The best (free) advice I can give you is to try to analyze your situation beyond the traditional object-oriented mindset and look at it from a business perspective.