Sometimes I think CS people are vocabulary crazy. When we start cataloging all of the popular design guides and architectures over the decades the primary question for me ends up being wtf is the difference between esotericly-named category A vs esotericly-named category B? I mean the only thing less readable than the average project's code is the average design guide.

Perhaps I'm not sophisticated enough (although having a masters in philosophy argues against that) but we want code to be less error prone, easier for new people to understand and use, and easier to update. Rigidly adhering to an incredibly complex design architecture that will probably be replaced by the next best design architecture in about 3 years seems like an exercise in futility.

I don't really believe a perfect, one size fits all architecture exists (neither do I think a perfect set of moral rules exists for every situation - and for similar reasons). Forcing a design pattern onto a bad fit can make things exponentially worse.

Programming is hard to do well. There's a lot of creativity and design required. We can look at some code and know that it's well-written or that it's a clusterfuck not because of a style manual dictating every decision but because we've had to work with shitty code and we've had the pleasure of working with excellent code.

I don't know if any of this is helpful or just a ridiculous side rant. Maybe what I'm trying to say is, don't try too hard to adhere to one pattern. They are all good only to a point. Focus on making excellent code (and remember that no one can define that exactly).