Application Architecture consistency

Just read a good article on Angular App Structure. 

I left a comment and as I wrote it I realized (duh) that a significant part of the problem is one of consistency: Organization by type is inconsistent with what the logical application architecture is. 

Over time, that inconsistency leads to bad design decisions and all other kinds of mistakes large and small. When there is consistency through the app from features to architecture to physical code, it makes it easier for everyone, easier to think and reason about the app, make design decisions, add more code, share a common terminology, work together etc. And when I say "easier for everyone" I include the product team, qa, management, designers and developers.

Thats not to say there can't be differences between logical architecture and its physical manifestation. Sometimes that is necessary. But I think its works best if the logical and physical are mostly in synch and material differences are exceptions. 

Building an large application is a big undertaking, many people, lots of $s. There's usually serious time pressures to get features shipped and considerations such as application architecture are not as important as shipping. This is understandable. A great architecture is no consolation if the product fails because it did not provide the features needed on time. So there's always a tension, I get that. 

• Build faster! 
• I need to refactor to build faster! 
• No time for that, build faster! 

At the HTML5 Developer conference last October, I attended a talk by the Yelp.com team on how they had to restructure their "monolith" app into smaller components because the monolith was causing problems (production deploy rollbacks, brittle code etc). This restructure has been going on since 2013, almost 2 years. Thats must be a significant investment. We all know technical debt will catch up with you, will slow you down and cost to cleanup. 

So I believe its worth using some precious time to: 

• think and brainstorm about the features in the application with other team members, devs, product team, designers etc

• creating some diagrams with boxes for those features (components) in the application

• identify sub-features (sub-components) within those features

• spend some time thinking/researching the application architecture you're going to use, aim for a physical structure thats consistent with the features in the application; especially for the big features 

• in many cases such application architectures are already available to you (see referenced link above), you just need to adopt it; most frameworks have best practices about this

You don't need to spend much time up front. It won't and doesn't have to be perfect, things will change and you will need to iterate. But you could certainly save yourself and your team a lot of pain later by taking some time now to try get it right. I'd suggest printing some of your component boxes diagrams and putting them on the wall so everyone understands the "picture". Plus over time you'll see it get out of synch and have to be updated, so forces you to stay current!

We recently completed an exercise to review our app architecture and identified our top level "feature" components. Within those top level feature components we identified sub-components. If I could have a do over, I wish we did this sooner and I wish the code base was organized by these features.

For example, when I look at Github I see an Account Settings feature component which has sub components of: profile, emails, notifications, billing etc.

Many apps have an Account feature.

Most apps also have Authentication, Authorization and User components as well.

So thats a start for you!

Common/shared components should be separated from feature components to enable easier reuse/maintenance/replacement. I'd note that within common/shared components I see at least 2 categories: ui components and non ui components.  

I'd recommend serious consideration be given to creating separate repos for common components, especially if could be used by other products/teams within/out the org. It doesn't take much to create a separate repo for a common component, especially common ui components which are often app agnostic. Create it as a bower (or npm) library. You can install from a private repo using bower so you don't have to make it public if you don't want. If done well, this makes it easier to refactor/replace such common in future too.

I recently built an angular component for enforcing date order. Its bower enabled so anyone can bring in and use. Once you do build such a library component once its easy thereafter. If I use it in my app and don't want it any more I can do a bower uninstall and its gone from my app. Easy to add/remove. Thats powerful.

"The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application" -
Justin Meyer, author JavaScriptMVC