Systems software design (SSD) is too different from application design to automatically use one conclusion for the other. Things like OS's and database engines are designed by mostly logical engineers for logical engineers.
Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.)
I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps.
I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.
Business and amininistration apps, on the other hand, reflect screwy random-seaming legislation and management whims, which often change in unexpected ways. Management doesn't care that much if their screwy rules and processes complicate automation. (Or don't comprehend the impact.)
I noticed this in debates where SSD experts showed code patterns that assumed too much uniformity between variations of concepts (sub-types, etc.). They just wouldn't fly in biz apps.
I lean toward using flags/tags to manage variations on themes instead of sub-typing, composition, or dependency inversion. Variation granularity has to be small in these domains.