The Heart of Software Architecture Is Weirdly Empty | by Daniel Niland | Nov, 2022

Books and articles on the subject rarely address why we build software, yet this understanding is vital to good design.

photo by Freddy Martinez Feather unsplash

in my last ArticleIn this article, I wrote about how object-oriented design can lead to crippling complexity. I don’t mean to claim that OOD is inherently bad – sometimes, it’s exactly the right pattern to follow.

But often, especially for applications involving complex states, OOD is a complete s**t show, and you’re the star (or maybe you just have a bit of a part). So, how can one avoid being put into such unpleasant production?

But before I jump into the specifics of this design versus that, we need to explore the fundamentals a little more. You can’t win the Tour de France without knowing how to ride a bike.

So, why do we make software in the first place? It all comes down to business logic.

The word itself, business logic, is unfortunate. It brings to mind friends shaking hands on the golf course between martinis (or still, business gets done — who knows, really?) The concept is in need of a rebrand.

Business logic can be understood as an expression telos of an application. telos Aristotle’s word. it is final cause of something; Its goal or basic interpretation.

here is an example telos, An apartment building is very different from a bowling alley; However, in many ways, they are similar. They are both buildings. They both need designers who plan and decide what materials to use. Construction workers probably use similar techniques for pouring foundations or building walls.

But if you pay an architect to design an apartment building and they build a bowling alley for you, that architect has failed no matter how well the ball rolls down the aisle. They haven’t created a space for you that is subdivided into easily accessible living units with all the modern living amenities. They have not fulfilled your intention, of the building telos – Its “apartment-buildingness.”

Depending on the complexity of the project, a telos can be subdivided. Often, there are narrow goals within the broad. telos That struggle. An apartment building must balance the space between common areas, living quarters, and infrastructure such as plumbing and elevators. It is the architect’s job to make sure all the pieces come together in a way that supports the extensibility telos of the building. It must be a great place with many different people living in the same building.

But zooming out is also instructive. most common telos To ‘envelop a space’ of any building.

Software architecture is very different from physical architecture, but considerations for telos Equally important. A video player is very different telos from embedded software that drives your automobile, and any complex telos can be subdivided. It is the job of the architect to deal with conflicting elements to work towards a higher goal.

But one can also zoom out to see the most normal telos for software. Here it is in the form of a diagram:

Behold! The reason for every software application ever written. Input is converted into output. Everything else about an application is meant to support this central mission.

And that “everything else” is what we usually consider to be software architecture.

Pretty much every software architecture book I’ve read has focused on “everything else”, not just telos (no matter what the idea of telos is expressed). It’s like opening a coffee table book about the world’s great buildings and discovering nothing but dazzling images of plumbing and door frames.

It’s understandable, I think. it’s easy to understand telos Of a physical building, yet it is very difficult to imagine the reason for a software application or to see the beauty of well-crafted business logic.

Software architecture, at least as is commonly learned in books, fits into our basic telos hence:

Software architecture enables the transfer of data

I am asking many of you here to change your perspective. software architecture is No telos But its form of an application. Architecture is the way in which data is organized to move data from transformations that satisfy the reason for its existence.

Think of the simplest application possible: “Hello World.” its telos This is to test whether you can create a working program in a given context. Input This is where the program begins. Conversion is that an empty value becomes “Hello World”. The output is that the string is written to some external view.

Not to say that there isn’t much going on here. The context can be very complex. The operating system that instantiates programs and the console that logs text is a surprisingly complex system with layers and overlapping telos But, from the point of view of the “Hello World” application, it’s all on the level of “material” reason.

Software applications are usually much more complex than “Hello World”. An application can input, transform or scale the output.

For example, FFMpeg can take an input, a media file, and convert it in several steps to produce multiple outputs, a transformed set of media files. The simplified diagram would look something like this:

Diagram showing converting one input into multiple outputs
Transformations can be combined to solve complex business logic.

I find the architecture of FFmpeg to be quite elaborate, allowing for flexibility around adding and configuring a variety of transformations for all media. But, it is still a relatively simple program in terms of telos Because the form and variety of its inputs don’t need to be scaled. You throw a media at it, and it does its job (admittedly).

Most real-world applications (or systems or platforms or whatever we want to call them) will be much more complex than a program like FFMpeg because they have to scale their inputs. their telos Demand that a heterogeneous set of data interact to produce different types of outputs.

Whenever you have multiple inputs, they should be at different times. Inputs can be separated by microseconds or years. For example, if someone presses the pause button on the player, that logic should interact with other processes in the player that have already been set in motion through other inputs. Is the user seeing the ad? do one thing. … a live stream? do another. …an interactive animation? yet another.

it’s a part of telos Influencing the other, modifying how both are expressed. This communication between changes is called state. And the state makes things more complicated. The combination of possible connections explodes toward infinity, but here’s the simplest idea:

State is a change that sends information to another over time.

I see state as more than just the data stored in a running process. It is any form of data that allows one part of business logic to affect another. Membership information?

If you’re looking at your system as a whole, it’s definitely state, even though it was input years ago. Statistics about viewing habits? It tells when it is used to target the end card of a video. Currently loading segment of video? Yes, it’s an easy one.

State is the potential energy one data change makes to power another. The kingdom is the key to unlocking further treasures. Without state, your application is no more than a utility.

And state management is absolutely the most important thing for a software architect to get right. The issue is not just handling the state at run time, which is quite difficult, but we are also dealing with the extension of the application. telos Rarely stands out of an application.

I’m going to move on to another analogy now (the more, the better, right?) Think of an application as a dance. Each change rotates its input and hands-off position to dance with the other changes.

Data needs to be transferred gracefully and over time. Often, there is little tolerance for error. If a single transformation fails to work correctly, it may not set the state correctly for the others, setting off a cascade of errors. But faltering changes are relatively easy to fix; You can always teach any dancer the right steps.

Dealing with the flow of dance is very difficult. If telos Our application is to throw a big dance, so our biggest mistake would be to create a maze on the dance floor. This maze can work well if it is designed to completely funnel the dancers into their correct places. But what happens when we start adding more dancers? What happens when we need to change the dance? When the form of application, the ‘architecture’, begins to obstruct the free flow of dance, real problems arise.

Hope you can see where I am going here. As I my . is described in final essayThe object-oriented design creates a maze on the dance floor by locking the execution flow. Every time we add a new dancer, we have less and less leeway as to where to weave them into the dance. Toes will be stepped on. Nose will bleed. Even if every piece of business logic is strictly correct, it can fail to delegate the right state at the right time.

So, how can we build an application that remains robust over time? Let’s start with a central principle:

  1. The state should remain predictable. Each part of the application should always be able to know when and how the state changes so that they can target the state at the right time. There is a problem here because of the increasing scale in two ways. First, more change jockeys to set the same state, changing the window in which the state can be true for any received change. This is one dancer stepping in front of another. Second, the receiving transformation can move around in such a way that it misses the correct position window. It’s a dancer doing a few more turns with the other partners, so they miss a handoff. Often the tolerance for error here is microseconds. To deal with these issues:
  2. The flow of execution should be reasonably flexible. If times change, we should be able to push some changes and weed out others. A dancer must be able to make the first move to prevent the other dancer from biting, or we must have a dancer be able to wait until the second one moves. Or, we may need the flow of execution altogether, re-choreographing the dance to better fit a new set of dancers. And to do this:
  3. Business logic should be reasonably portable. We need to take a change and transfer it from one point to another in the execution flow, whole and unchanged. If a single business logic is spread across multiple classes, as is often the case in object oriented design, it becomes very difficult to proceed as a single entity. It is as if the dancer’s hands and feet are scattered across the floor, others dancing with separate hands and feet. You will have to go to collect them and put them back on the body even after turning freely so that the legs and arms are no longer the correct length. … well, maybe the analogy is a bit broken there, but it still makes sense, doesn’t it?

Leave a Reply