Last words on UI architecture before an AI takes over

Big Ball of Mud is the current state of the UI architecture, despite component-based composition.

Components are notenough

Components and composition are just one piece of architecture. You still need to know how to compose pieces without recreating the Big Ball of Mud using a new (not really) shiny components-based approach.

Components are too generic to actually solve architectural problems. They are comparable to the bricks. You can for sure use bricks to build a house, but there is so much more to building a house that bricks arent even 10% of what you need to use.

New Architecture?

We spent decades defining methodologies and principles for great architecture and yet here we areevery new job will surprise you with new ways of creating an utterly broken architecture.

Is everyone stupid? Did nobody read about SoC, SOLID, DRY, KISS, WTF, GoF, GRASP YAGNI, WTF, Atomic Design, DDD, Onion, Clean Architecture, etc?

I am sure everyone heard at least one or two of those and maybe even understood them, so whats the problem? Why cant we have a better architecture in practice?

Maybe all we need is another, better architecture that solves all the problems? (Not really)

Theory vs.practice

These are the most popular reasons why your organization will inevitably fail at the architectural level:

1. Many well-known principles and methodologies are conflicting.
2. Requirements change over time.
3. Organizational restructuring.
4. There are no generic good ways to enforce a particular architecture.
5. Poor communication of the applied architecture.
6. Practical implementation difficulties.

Conflicting principles

Lets take one example: DRYDont Repeat Yourself vs. High Cohesionkeep related code close.

In theory, they both sound great, though both of them fall apart when you have 2 independent features that need the same function. I understand this is too theoretical and it never happened to YOU in the real world /s, but bear with me for a second.

As soon as you have to share a function between 2 features you have 3 options:

1. Let feature A import that function from feature B directly and marry both features together in the sense one has to know about the existence of the other.
2. Move that shared function into some shared directory and use it from both places.
3. Copy that function into both features

If you are reusing that function, you are breaking High Cohesion. If you are copyingyou are breaking DRY.

And this is just one simple example, there are many more.

Changing requirements

In the modern world of startups, every company starts with some small prototype that can be manufactured quickly and then hopes to evolve it into something better.

When building things quick and dirtyyou dont have time for good architecture, let alone you dont know yet what good means for that particular product.

Product is changing and so are the requirements. You either have decades of experience and can predict what architecture needs to be because you saw this very same thing happening already or you will start with some baseline architecture that minimizes your risks.

Organizational restructuring

Its not a secret that the architecture needs to not only be designed around the product requirements but also around the people working on it.

If you have a team of 2 engineers, exchanging information, agreeing on architecture, and keeping things consistent is one million times easier than having a team of 20 people. (please teach me the math here /s)

Every product starts with a small team and then adds the team members over time. People join, people live and communication pathways change all the time.

Can we have an architecture that is correct no matter how many people work on the product?

Enforcing an architecture

If a magical tool existed that could enforce every principle and every architectural decision that is used on a product, we could have a consistent architecture and much better communication of it.

People dont read docs. They dont read not because they dont know how to, but because they dont know what those words mean in their specific context, and learning it is hard work.

Tools can tell a person to read something when they are about to make a mistake or create an inconsistency, but creating such tools is hard because many violations of principles are hard to detect in code.

We definitely need tools to communicate architecture, and yet, do we know many tools that try to do that at least on some basic level?

Poor communication

Documentation is hard. Documentation of principles and methodologies is harder. Documenting them well as a by-product of some product workimpossible.

Your internal documentation around principles and architecture will always suck unless you have people who have a serious level of dedication for the topicaka architect.

How many companies have you worked for that have people with architectural roles?

Tactics vs. logistics

One dude said once:

The amateurs discuss tactics: the professionals discuss logistics.

Tactics in our context are the same as abstract principles and methodologies. Those are just words that dont tell you what to do in your context because they are too abstract and conflicting.

The missing piece in the industry is a set of principles that can be well understood and applied in practice that go along with tools that help to enforce them.

This is the logistics analogy.

Solution

Am I here to just criticize the current state or to move the needle? Well, without agreeing on critiques we cant move on to something better. Can we come up with something better? I believe so.

I expressed some ideas in my talk in 2018 with the title Feature Driven Architecture https://www.youtube.com/watch?v=BWAeYuWFHhs

There is nothing fundamentally new in it, it is a collection of well-known ideas put together into a single practical architecture.

If you like and retweet this article hard enough, I might work on defining those ideas and examples more clearly in this repository https://github.com/kof/feature-driven-architecture

Features are everything

The word "features" is the most common to describe application-level components. An application will have features added, removed, modified. It will have big features, small features, life-changing features. Features that make you proud of yourself, features that will embarrass the entire company. Features are the most important piece of every application.

This is why it is so important to make it your life goal as an architect of an application to make sure a feature can be added, removed, or extended with the least amount of work.

Being able to completely remove a feature without leaving pieces of logic left behind spread over the entire application is the key to a maintainable product.

An ultimate test for any architecture should be to remove a feature directory from the file system and the application should stay fully functional without it.

An ideal feature contains everything it needs.

Principles of afeature

These are the most important principles that have to be followed in a Feature Driven Architecture:

1. A feature can not know other features or its consumers.

Its simpleyou will break one feature when you change the other otherwise. You also cant remove one feature without affecting another, if you break this principle.

2. A feature has to express its dependencies declaratively.

If there is data or any other dependenciesit has to express them declaratively and a consumer should be able to provide them.

Much like a component, features dont live in a vacuum, they have dependencies. To name a few: data, static artifacts like images, libraries, functions shared between features, knowledge of app architecture, build system, and more.

Dependencies are what makes it hard to build features that are fully encapsulated and integrate well with the rest of the application. Thats why on the architectural level we can only define basic rules of behavior, but not the specifics around implementation details because those will vary depending on your stack and particular business requirements.

An ideal feature doesnt have dependencies.

3. Be disposable

Much like a component, a feature has to be disposable. You need to architect the feature so that you can remove it easily. Thats the whole point.

Screens

If one feature doesnt know any other feature, there has to be something else that knows all the features, otherwise, we will render a vacuum.

Screens have to follow the same principles we described for the feature for the exact same reasons. In addition, it acts as a features manager:

1. Doesnt know about otherscreens

2. Renders thefeatures

A screen can import a feature and access its public API, including its rendering interface and its declaration of dependencies. The screens main goal is to render the features on the screen.

3. Provides dependencies

In case a feature can not satisfy its dependencies itself, a screen will have to provide them. It could be static artifacts, data, or anything else. Important is that if a feature can provide those things itselfit should. I can only see the need to express dependencies when the dependency is outside of features scope or it is something 2+ features on the screen depend on, so it would potentially make sense to hoist the logic to the screen.

4. Connects thefeatures

Sometimes one feature depends on something that some other feature has or does, but since features cant know about each other, this dependency has to be expressed via a simplified protocol.

If the dependency is dataone feature has to express what data it requires via an interface and the screen will pipe that data from one feature into another while trying to keep the least amount of knowledge about its contents.

The more screen knows about each featurethe harder will it be to remove a feature from the screen.

Clusters

Sometimes a set of independent features is used on 2+ screens together as a set. You dont need a cluster to achieve that if a feature is fully self-contained, but if a feature has dependencies provided by the screenyou would have to duplicate the setup logic that wires up those features 2+ times for each screen.

If that setup code a feature needs is trivialyou may want to avoid having a cluster to avoid the need for this additional abstraction.

But if you end up needing a clusterthe rules it follows are similar to a feature:

1. Doesnt know about other clusters
2. Doesnt know about screens
3. Knows all features from that cluster and exposes a declarative interface for the screen.
4. Provides features with dependencies just like a screen.

Shared

Sometimes you need to share a function between features, screens, or clusters that has business awareness. This is where a shared space comes in handy.

Shared space has one rule to followit cant directly depend on anything outside of shared except the libraries. It cant depend on a feature, screen or a cluster.

Libraries

The final and the most low-level piece is a library. A library has no knowledge about business logic. It can be published to or installed from an Open Source repository and can be shared between businesses. You can have a lib directory inside the product or you can treat the installed package from an external source as a lib. One example is the node_modules package, if it doesnt contain a business-aware logicit's a library.

To sum it up, my proposal is to split an application by a number of principled types that would let your application be maintainable, guided by the need to have built-in discoverability, disposability, and scalability. The proposed types are in the order from higher to a lower level of abstraction:

1. Screens
2. Clusters
3. Features
4. Shared
5. Libraries

I am certain the constraints I expressed are basic and there is more to it. We need to work on a well-defined spec for them. I am also certain that enforcing those constraints should be automated one way or another and we need to build tools and interfaces to make a consistent architecture.