BADGER 1 has a folder structure including the word "module", but isn't really modularized. For BADGER 2, we have to decide how this topic should be handled.

We have several options:

• Remove all modularization, build monolithic application: This removes all the burden of thinking of a suitable module structure and therefore speeds up the development process. As a drawback, future enhancements are most probably not well separated from the existing system which may lead again to unmaintainable code more easily.
• Implement more or less the stuff of BADGER 1 as "core", but define extension points at suitable places for future enhancements. This is a compromise between completely modularized system and monolithic approach.
• Spend a lot of thoughts into a real flexible core model and implement all instances as modules. This may unleash a lot of possibilities for future enhancements, but needs a really thoroughly planned base (which, as I guess, would still evolve as we cannot anticipate all requirements).

I'm voting for full modularization. In my thoughts, we would define some base concepts suitable for this type of application (like "Transaction", "Account", an system of categorization etc.). All instances of this (like "Bank Account" vs. "Stock Depot" vs. "Telephone Bill") would be modules.

i agree. a hard split between core and modules is a really splendid idea.

I voted for full modularization. I have seen the middle way in OS commerce and it doesn't work. It leads to all kinds of problems when people includes different extensions in different ways. Often they leed to serious problems in stability and speed

additionally there is one effect with the semi-middle way we can already see right now: there are parts of the core we can not account for because someone coded them who left the team and didnt document.
the smaller and more compact the core, the higher the probability that we will be able to maintain it.

me too

Jürgen