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.
Post History
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. a...
#3: Post edited
by
toraritte
·
2023-10-13T15:17:18Z (about 1 year ago)
Clarify "program"
- 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 programs have in common are:+ the employees providing the services (e.g., one instructor can help out different programs; a manager can overview multiple departments / programs; a department can run multiple programs; 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 programs. Perhaps table names reflect which 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][1], so one could design a database schema for programs A, B, and C, and the application would hide this detail. (It is also possible to make [cross-database queries with PostgreSQL][2].)- + 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 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?
- [1]: https://www.postgresql.org/docs/current/ddl-schemas.html
- [2]: https://stackoverflow.com/questions/46324/possible-to-perform-cross-database-queries-with-postgresql
- > 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][1], 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][2].)
- + 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?
- [1]: https://www.postgresql.org/docs/current/ddl-schemas.html
- [2]: https://stackoverflow.com/questions/46324/possible-to-perform-cross-database-queries-with-postgresql
#2: Post edited
by
toraritte
·
2023-10-11T17:11:28Z (about 1 year ago)
What architectural design patterns can one choose from to develop a client management system with disparate business domains inside one organization?
- What software architecture are available for developing an application with multiple business domains that only share some common aspects?
To give a less generic example, non-profits providing services for people with disabilities have multiple departments, each operating on one or more federal or state grants that have different reporting and operating requirements, budgets, etc. Many (most of?) times the only things these the departments / programs have in common are:- + the employees providing the services (e.g., one instructor can help out different programs; a manager can overview multiple departments / programs; a department can run multiple programs; 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 the departments / programs. Perhaps table names reflect which program / department 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][1], so one could design a database schema for departments / programs A, B, and C, and the application would hide this detail. (It is also possible to make [cross-database queries with PostgreSQL][2].)- + 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 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?
- [1]: https://www.postgresql.org/docs/current/ddl-schemas.html
- [2]: https://stackoverflow.com/questions/46324/possible-to-perform-cross-database-queries-with-postgresql
- 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 programs have in common are:
- + the employees providing the services (e.g., one instructor can help out different programs; a manager can overview multiple departments / programs; a department can run multiple programs; 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 programs. Perhaps table names reflect which 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][1], so one could design a database schema for programs A, B, and C, and the application would hide this detail. (It is also possible to make [cross-database queries with PostgreSQL][2].)
- + 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 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?
- [1]: https://www.postgresql.org/docs/current/ddl-schemas.html
- [2]: https://stackoverflow.com/questions/46324/possible-to-perform-cross-database-queries-with-postgresql
#1: Initial revision
by
toraritte
·
2023-10-11T14:45:28Z (about 1 year ago)
What architectural design patterns can one choose from to develop a client management system with disparate business domains inside one organization?
To give a less generic example, non-profits providing services for people with disabilities have multiple departments, each operating on one or more federal or state grants that have different reporting and operating requirements, budgets, etc. Many (most of?) times the only things these the departments / programs have in common are: + the employees providing the services (e.g., one instructor can help out different programs; a manager can overview multiple departments / programs; a department can run multiple programs; 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 the departments / programs. Perhaps table names reflect which program / department 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][1], so one could design a database schema for departments / programs A, B, and C, and the application would hide this detail. (It is also possible to make [cross-database queries with PostgreSQL][2].) + 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 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? [1]: https://www.postgresql.org/docs/current/ddl-schemas.html [2]: https://stackoverflow.com/questions/46324/possible-to-perform-cross-database-queries-with-postgresql