What software architecture are available for developing an application with multiple business domains that only share some common aspects?

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.

posted about 1 year ago

CC BY-SA 4.0

matthewsnyder‭

2209 reputation 52 59 259 92

Important note: this is primarily based on personal fairly long experience with monolithic architectures and limited microservice-based architecture combined with others' experience with microservice-based architecture

Based on your rather vague requirements and the data volume indicated in the comments, I suggest:

Modular Monolithic Architecture

This can be a good way to start a project even if it will eventually need some microservices (for scaling reasons mostly). This article provides a very good introduction about this architecture, so I will only add some highlights here:

• modules should have clear boundaries. This avoids what you have noticed in legacy systems (messy/disastrous) and can be achieved by using events or a CQRS-like architecture, thus avoiding a direct coupling between modules.
• easier deployment
• simpler infrastructure
• less network overhead (mostly happens in memory)
• easier to reach data consistency, since a transaction does not span to multiple services
• allows for a module to be migrated should it have special scalability needs, require development by another team or it requires to be rewritten in another framework

This article goes deeper into the topic.

For the particular architecture at the module level, I recommend using a clean architecture, as shown in this article.

Upfront separation

If you know that one module of the application has special requirements, it makes to define it as a special service. For example, it is very likely that the employee module should have much more strict security constraints than another module due to the nature of its data (e.g. encryption at rest, encryption in transit).

It would make sense to define it as a separate service with its own small database.

Sacrifice some DRY in order to favor decoupling

This means that you should avoid reusing business logic between the project types unless it is something very generic like an economical indicator that has a universal formula or similar. This ensures that each project type can evolve independently and reduces the likelihood of getting the "mess" found in the legacy projects.

This article explains in very simple terms how sacrificing DRY within reason can lead to a better result.

Broadly speaking this approach also increases stability:

• with business logic sharing: a change request makes you wonder how other project types are affected
• with less/no business logic sharing: a change request affects only the changed project type and you know for certain that other types are not affected. The worst case is that the other types have an old, but stable business logic, as opposed to a possibly broken business logic.

posted about 1 year ago

CC BY-SA 4.0

Alexei‭

5003 reputation 112 101 690 486