I know questions like this has been asked before. But none of them truly answered me.How to keep a big and complex software product maintainable over the years?How do you organize highly customized software?...We're working on a software that has a lot of rules and conditions. Also, those rules change frequently.So far we've used many designs and techniques to cope with the requirements and implement them. To be more specific, let us focus on the following examples:Using configurable options, so that values can be changed easily by business people, like the amount of debt a customer can undergo.Problem: Soon there are like hundreds of configurable options, and even naming them becomes a nightmare, let alone managing them, changing them, tracking them in code, etc.Using small satellite project files as additives to the main engine (something like extensible workflow), so that new rules can be added hot, and also unwanted rules can be removed from the process pipelines.Problem: Soon the number of project files become so huge that the file-system management of the projects becomes a pain in the ass. What if for a short period of time business team needs a special customization that only lasts for two months, and then it should be removed from the system. Something like prepaid registration to track user-behavior for making the real decisions. Or a rule as simple as banning customers with suspicious activity that should be launched really soon.It seems that our team is going the wrong path altogether. So how a team can handle creating highly-complex, highly-changeable software when it encounters the specific problems mentioned? What points should that team consider? Are there specific architectures or designs that will help us creating such software?
How to write highly changeable, highly complex software?
design;architecture;complexity;business logic;changes