Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on What software architecture are available for developing an application with multiple business domains that only share some common aspects?
Post
What software architecture are available for developing an application with multiple business domains that only share some common aspects?
NOTE
The meaning of the word "program" below is(PROGRAM) A federal or state initiative that offers grants for non-profits so that they can provide service at low cost or free of charge.
and not a software application or online service. When I mean software, I use "application".
(Thank you @matthewsnyder for pointing this out!)
For example, a non-profit provides services for people with disabilities that has multiple departments where each department can offer multiple "programs". A program is funded by a federal or state grant, and only accepts clients of a certain demographics, such as 55 and older. Each program has its own budget, reporting requirements, scheduling rules, etc.
Usually, the only things these federal/state programs have in common are:
-
the employees providing the services (e.g., one instructor can help out different federal/state programs; a manager can overview multiple departments / federal/state programs; a department can run multiple federal/stateprograms; etc.)
-
the clients receiving the services
These are the architectural options I can think of:
1. Monolith
One application operating on one huge database schema that have all the info from all federal/state programs. Perhaps table names reflect which federal/state program they belong to.
Pros:
- Easy.
Cons:
- I haven't seen one solution yet that wasn't messy (or downright disastrous).
2. One application, but more granular database structure
PostgreSQL has schemas, so one could design a database schema for federal/state programs A, B, and C, and the application would hide this detail. (It is also possible to make cross-database queries with PostgreSQL.)
- How would one share the clients and employees though? (Using an extra schema just for this data?)
Pros:
- Less cognitive load when trying to understand the organization.
- Easier to document.
Cons:
- More involved design process.
- App framework should support schemas (otherwise it can be challenging to do queries).
3. One app and one database per federal/state program
I guess this is what microservices are? There could still be one unified frontend.
Pros:
- ???
Cons:
- Complexity.
- Many points of failure.
- Deep knowledge about managing all the infrastructure.
4 - N. What else?
What haven't I thought of? Did I get some of the ones above totally wrong?
3 comment threads