Having all features in single application

Question

We have following windows services that connects to a single database (name it mainDb) but has different features:

1. Fetches data from Attendance Machines and stores in mainDb
2. Fetches data (ie recipient, content) from mainDb and send SMS via SMS gateway
3. Fetches data (ie recipient, content) from mainDb and send emails
4. Monitors machines connected to the mainDb server and stores health data (connectivity, memory etc) into mainDb

One of my team-member thinks that its a good idea to create a single service which will server all above purposes based on the features we configure (one or more features may be disabled in a particular environment); gives reason that it will be easy to deploy and maintain a single app.

On the other side, I am in a favour of keeping them separate to maintain the code quality, reduce downtime due to maintenance, keep other features available if one is compromised due to run-time failures.

Needs suggestion.

Answer 1

Needs suggestion

I think you are definitely right about "separating" things, but what to suggest? The design principle of modularity, componentization and why, service oriented architectures, microservices... if there is an architectural lesson to learn since day one is everything but the monolith.

which is a better approach in the given scenario?

In general, go with a different component for each different task/responsibility (in UML terms, what you'd put in a components diagram), to each component then corresponds (in the case you have presented at least) a specific, distinct service (what you'd put in the deployment diagram).

That said, in the specific case you have presented, I'd just lump 2 and 3, as those look the same to me except for the "target channel", namely, abstracting a little bit, that looks like a "communication/messaging component". As for 1 and 4, those definitely look to me like separate components for independent requirements.

Anyway, please just take those as educated guesses, where I rather hope the "method" is clear: actual solutions very much depend on the detail of the specific functional requirements, then also on technical considerations (such as which technologies, but even which competences, are available).