Breaking functionality to separate DQMH modules?

[1984]

Hi,

I'm working on a functionality handles the users in our system. There are three key areas identified:

1. functionality responsible for saving / loading user config file from disk/database, checking if an input username+password is a valid login, add / delete users etc. This is part will never show up to the end user, this is the core functionality.

2. A login interface displayed to the user. Username / password can be entered here

3. A user management interface displayed to a user if he has the right credentials after login. On this one users can be added/deleted, credentials can be changed etc

I started with one module responsible for everything, but I started to get a bit concerned about feature creep. Breaking these to three different DQMH modules (core, loginGUI, managementGUI) would get rid of the feature creep and it makes possible to change the design of the GUI parts in the future (not a concern though). The cost is having three modules instead of one which makes the project structure more complex and it will be harder to debug the modules because of the cross communication.

I know that the decision is very much subjective, but I'm wondering which route would you choose.

Merry Xmas!

[Olivier-JOURDAN]

Hi,

You're asking yourself the correct questions 👍

My advice here would be to have 1 module that deals with the data. No UI, only request to add/modify/remove user, check credentials…

Your login interface (#2) is too simple to create a module.

#3 is your main UI. Create a module for it.

The first module will be straightforward to test and maintain. If you change how data are stored, you'll just modify internal code. your public API will not change.

The second module will rely on a well-tested module. You'll focus your dev on the UI behavior.