How do I avoid the complexity concerns of frameworks while keeping my team marketable?
- by Desolate Planet
When deciding upon how to design a software project with my colleagues, most suggestions tend to be for using specific frameworks "because it's popular in the job market" or "that's the framework that gets recruiters on the phone," and never what I'm looking for which is, "because it's a good fit for the project as it makes the system more adaptive to future changes and makes life easier for developers."
I didn't start looking at projects in this way until I started reading up on domain-driven design. I've found that the actual domain is hidden deep under the frameworks used and it's hard to learn the business processes that have been implemented by the software product.
Is there a way to marry the two competing goals: getting exposure as a development team while still being able to avoid complexity? Are frameworks that compromise, or are there other solutions out there?
