Post History

If I ignore the example and answer the title generally: You would put the common logic into a third piece of software that becomes the dependency of both domains.

For example, let's say you are writing software for a company that has two domains of business: They sell construction tools and materials for DIYers, and they act as contractors to build stuff for people.

The retail side might need to keep track of things like inventory, orders, shipping, returns, warranties. It would need a credit card processing system. This would be one codebase, but it could be made up of many programs (one repo for mobile app, one repo for public website, one repo for backend...).

The contractor side would need to keep track of jobs, quotes, invoices (people probably don't just swipe a credit card to pay for a million dollar house build), loans. For simplicity, let's say the contractors just buy supplies independently - you have to keep track of business expenses. This would be another codebase, similar to the previous one, but maybe it includes things like software for handling building plans, permits, building codes.

The common stuff is that all these employees have salary data, benefits, taxes, vacations etc. Let's say they operate out of the same store: Keeping track of stores, their expenses, who works where would be common. This would be a common codebase.

For example when someone buys a tool online, the retail app will have to call the common app to check what stores are closest, so it can show the "in stock at a store near you!" message. When people request a construction quote, the contractor side would also query the same thing from the same place.

In simple cases the common logic can be a library, which the other codebases import. If there's a lot of data, it might have to be a database or an API or microservice that they connect to and query. This means you will always have at least two interfaces: Retail-common, and contractor-common. But luckily no retail-contractor interface is needed, those two don't need to know about each other.

----------------

In the example you give with the non-profit, I don't know if a separate codebase is needed. It sounds like the problem is actually just how to structure the database tables.

You would just have a set of tables for things in domain 1 only, a set of tables for domain 2 only, and a set of common tables (employees, clients). The per-domain tables would connect to common tables with foreign keys.

So for example the common clients table would have the client ID, name, phone, email of the client. The table for clients going through income adjusted aid would have the client ID, income, other stuff. You would join the income adjusted table with the common client table to get the full data, and that would also remove clients who are not going through the income adjusted. Maybe veterans would have a separate table with client ID, branch of military, date of service, military ID, etc. That would also join to the common clients as needed.

The schemas are not important here. Schemas are like folders for organizing your tables, when you have a lot of tables. They can make it easier to find tables (if you know the schema, you have to look through a smaller list) and bulk-grants (you can give people permission to see all tables in a schema), but everything you can do with schemas you can do without just as easily.

You can see how this is analogous to the general software solution I gave above. The difference is that databases are a lot simpler, and you might not need the overhead of "multiple codebases". It can all live in the same piece of software, you just separate common data using tables.

Another way to describe this would be to use *normalized tables*.