Eric Hawthorne has architected, designed, and developed object-oriented software and distributed systems professionally since 1988, beginning and for 10 years at Macdonald Dettwiler, a Canadian systems-engineering company, where among other things, he had the opportunity to absorb some architectural technique from Philippe Kruchten.
WHEN CHOOSING SOFTWARE FRAMEWORKS as a basis of your system, you must consider not only the individual quality and features of each framework, but also how well the set of frameworks that make up your system will work together, and how easy it will be to adapt them to new software you may need to add as your system evolves. This means you must choose frameworks that do not overlap and that are humble, simple, and specialized.
It is best if each framework or third-party library addresses a separate logical domain or concern, and does not tread into the domain or concern of another framework you need to use.
Make sure you understand how the logical domains and concerns addressed by your candidate frameworks overlap. Draw a Venn diagram if you need to. Two data models that overlap substantially in domain, or two implementations that address very similar concerns but in slightly different ways, will cause unnecessary complexity: the slight differences in conceptualization or representation ...