Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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?

+1
−1

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?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

3 comment threads

"Program" a bit confusing (2 comments)
Modular Monolithic Architecture (2 comments)
The structure of this question is kind of awkward. For example, let's say these *were* all the option... (4 comments)
The structure of this question is kind of awkward. For example, let's say these *were* all the option...
Derek Elkins‭ wrote about 1 year ago

The structure of this question is kind of awkward. For example, let's say these were all the options. Are you expecting an answer that's just, "Yes, those are all the options"? What I think your actual question is is "what is a good software architecture for your problem".

That said, you haven't really provided enough information to answer that question, at least not clearly. Do the differences between programs actually lead to differences in the structure of the tables? Does a table for program A have different columns from an analogous table for program B? Is it possible to make a reasonable design where creating a new program is as simple as inserting some rows? I would assume not, but the requirements you listed don't jump out at me as things that should require different database structures.

toraritte‭ wrote about 1 year ago

The structure of this question is kind of awkward. [..] What I think your actual question is is "what is a good software architecture for your problem".

You are right, and this is not a good question, but one that reflects my ignorance in this topic. Also, your suggestion is right, but spending years on Stackexchange sites, this variant didn't even occurred to me, because questions of this form get closed or deleted right away. (Well, I posted this there too, but got closed and deleted within hours anyway, so thank you for taking the time for providing constructive feedback:)

toraritte‭ wrote about 1 year ago

you haven't really provided enough information to answer that question, at least not clearly.

I didn't want to inundate readers with the details when the database structures are indeed fundamentally different (should have spelled this out probably), and the only entities common are the clients and employees.

Do the differences between programs actually lead to differences in the structure of the tables?

Yes. One may be able to coerce one or two table to serve multiple purpose, but it would be a mess. (Talking from experience as this is what the 2 previous "professional" devs did, after we decided to do this in-house...)

toraritte‭ wrote about 1 year ago

Does a table for program A have different columns from an analogous table for program B? Is it possible to make a reasonable design where creating a new program is as simple as inserting some rows? I would assume not, but the requirements you listed don't jump out at me as things that should require different database structures.

The programs are different enough that these gymnastics will lead to a mess.

Again, I appreciate your questions because it is now clear that if I can reformulate this question by providing the right amount of extra details to make it clear, I'll probably be able to answer my own question..:)