Category: Clean Architecture

Clean Architecture – Chapter 14 | Component Coupling | SAP | The Stable Abstractions Principle

May 27th, 2023

So far we have discussed The Acyclic Dependency Principle and Stable Dependencies Principle, in this post we will go through Stable Abstractions Principle

A component should be as abstract as it is stable.
Robert Martin

High level architecture/policies are part of software and they should be present in a component that is stable, because we don’t want them to change often. However, if we put these high level policies into a stable component, then the code representing these policies would be difficult to change. And that could make the overall architecture inflexible.

So where should we put these policies so that they are stable as well as flexible. The answer is Open Closed Principle. This principle as we have seen gives us the opportunity to have classes that can be easily extended without modification using Abstract classes.

We can see that SAP creates a relationship between stability and abstractions. It says that a stable component should also be abstract so that it’s stability does not prevent it from being extended. So, for a component to be stable, it should contain interfaces and abstract classes.

SAP + SDP = DIP for components

SDP says dependencies should run in the direction of stability. SAP says stability implies abstraction . So dependencies run in the direction of abstraction.

Measuring Abstraction

Abstractions A = Na / Nc

where Na -> number of abstract classes and interfaces in the component

Nc -> number of classes in the component

A ranges between 0 and 1, 0 means component has no abstractions, 1 means, component has only abstract classes and interfaces.

The Main Sequence

Components on (0, 1) are maximally stable and abstract. Components at (1, 0) are maximally unstable and concrete. Other components lie on the line between these two components depending on the degree of stability and abstraction.

The Zone of Pain

Component on (0, 0) is highly stable and concrete. It is rigid. It cannot be extended as it’s not abstract, It is difficult to change because of its high stability. The area around (0, 0) is called zone of pain.

There are few components that lie in this area. Example – Database schema. These are volatile and concrete and many components depend on them.

Non volatile components are harmless in this zone as they don’t change. Only the volatile components cause pain like database schema mentioned above.

The Zone of Uselessness

Component at (1, 1) is maximally abstract and has no dependents. These components are useless and so the zone is called zone of uselessness.

These are generally dead code often leftover from abstract classes that never were implemented.

Main Sequence

Components that lie on this line are not “too abstract” or “too stable”. It is depended on to the extent that it is abstract and it depends on others to the extent it is concrete. As good architects, we should try to place our components on this line.

Distance from the main sequence

Distance or D = | A + I -1 |, range is between (0, 1). 0 indicates component is on main sequence, 1 indicates it is far from main sequence.

Using this metric, design can be analyzed for its overall conformance to main sequence. We can calculate D metric fir each component. Then based on its value, component can be evaluated and changed.

Thanks for stopping by! Hope this gives you a brief overview in to Stable Abstractions Principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 14 | Component Coupling | SDP | The Stable Dependencies Principle

May 20th, 2023

In our previous post, we discussed The Acyclic Dependency Principle, in this chapter we will go over next principle called SDP (Stable Dependencies Principle)

Depend in the direction of stability
Robert Martin

We need to ensure modules that are easy to change should not be depended on by modules that are harder to change.

What is a stable component?

Let’s say we have module X, and we have three modules that depend on X. Then X is referred to as Independent or Stable component as it has no external reason to change.

Let’s say, we have module Y which depends on three modules, so any change in any of those three modules would cause Y to change and so Y is referred to as Dependent.

Stability Metrics

Fan-in – Number of incoming dependencies, i.e., number of classes outside component that depend on classes within the component.

Fan-out – Number of outgoing dependencies, i.e., number of classes inside component that depends on classes outside the component.

Instability –

I = Fan-out / (Fan-in + Fan-out)

The range of this metric is between 0 and 1.

I = 0 => maximally stable component, component X from above example

I = 1 => maximally unstable component, component Y from above example

As per SDP, I of a component should be larger than I of the components that it depend on. I should decrease in direction of dependency.

Not all components should be maximally stable as that would create a very rigid system. We need a balance of stable and unstable components. Ideally in our system, we should have unstable components on top and then should be depending on stable components at bottom.

Thanks for stopping by! Hope this gives you a brief overview in to Stable Dependencies Principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 14 | Component Coupling | The Acyclic Dependency Principle

May 13th, 2023
So far we have gone through defining component and understanding what makes a component in previous chapters. In this post we start looking into principle that talk about the relationships between component. Let’s start with the acyclic dependency principle.

Allow no cycles in the component dependency graph
Robert Martin

A very common scenario that we developers face – We are working on a project, make some code changes, verify it’s working, so log out for day/commit the changes. Next day or few days later, we find that our integration tests are failing! Root cause comes out to be a change in one of our dependencies. This leads to either reverting our change or working on fix. The author calls this “morning after syndrome”.

Solution to this problem of running into frequent changes caused by changes in dependencies – The Weekly Build

The Weekly Build

As per this, developers work for 4 days in a week on their code and on fifth day they integrate their changes and build the system.

Now this could work when the team is small/the system is small so there are fewer teams. But when the system would grow, components and teams owning those components would grow. Eventually we would find that it takes more time to integrate and so pushing the integration days one day back. Ultimately a build per week won’t be sufficient and we would starting doing a build every two weeks. This could increase to month!

Clearly this solution cannot work for large systems.

Dependency Cycles elimination

The solution is to partition the development environment into releasable components. Each component could have its release versions with each change. The components consuming these changed components can then decide to move to new version or keep using the previous ones. This reduces the dependencies between teams and they can work independently.

The key for this approach to work is – When components depend on other components, there should be no cycles.

Say we have three components A, B, C. A depends on B, B depends on C. There will be a cycle if C would depend on A. If there is no cycle, any changes in A would force changes in B and C. Any change in B would only force C to change, A is safe. Any change in C would not force any change in A or B.

However if there is a cycle, then any change in A, B or C would need changes in all components.

So if there are cycles in the way our component depends on each other, we need to break it –
1. Use DIP (Dependency Inversion Principle), invert dependency by using interfaces.
2. Add the common classes between two components to a third component and then depend on that component.
Top Down Design

When we start building the system, we could be grouping classes based on usability. Few iterations later, we might worry about reusability of components and start moving around classes by creating new components and new dependencies between them. We can see the component structure keeps on evolving based on the requirements at each stage of our development. And so we cannot design this structure at the beginning in top down manner.

Thanks for stopping by! I hope this gives a good preview into acyclic dependency principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 13 | Component Cohesion

May 6th, 2023
In our previous post, we went through what a component is? Next question that comes is – Which classes go in which component? This chapter defines three principles to keep into mind while grouping classes into components –
1. REP: The Reuse/Release Equivalence Principle
2. CCP: The Common Closure Principle
3. CRP: The Common Reuse Principle
The Reuse/Release Equivalence Principle

The granule of reuse is the granule of release.
Robert Martin

All of us are familiar with module management softwares like maven, gradle, etc. These software helps us reuse classes from other dependencies in our projects. We have seen that every module that is part of these systems comes with a release process and release numbers.

The release numbers and the release documentation helps the consumer in deciding whether to move to new version or remain on an old one.

REP, on architectural level means that classes which form a component must belong to a cohesive group. They should not be a random group of classes, but should have some theme/purpose which they all share. In other words, classes in a component should be releasable together.

What would be the outcome if we group random classes together? The consumers would know about it, they would know that they depend on our package and it has classes which don’t make any sense to be in our package. They would know that any change in those classes would also unnecessary force them to change. This would show our weak architectural skills.

This principle, although very important, gives a weak advice. It says similar classes should be grouped together, but, doesn’t have a strong criteria that architects can follow. The weakness of this principle is compensated by the other two principles.

The Common Closure Principle

Gather into components those classes that change for the same reasons at the same time. Separate into different components those classes that change at different times and for different reasons.
Robert Martin

This is similar to Single Responsibility Principle. SRP stated to keep methods that change for different reasons in separate classes. CCP states to keep classes that change for different reasons in separate components.

Following this principle ensures that if something needs to change then only one component is affected as it has all classes related to that change. We would need to only redploy that component. The other components who depend on that component would not change.

This principle is also similar to Open Closed Principle. OCP states that classes should be closed for modification, but open for extension. CCP augments this principle by keeping the classes which are closed to same type of changes together in one component. So, if change comes in requirements, only few components change.

The Common Reuse Principle

Don’t force users of a component to depend on things they don’t need.
Robert Martin

This principle keeps the classes that can be reused together into same component.

When component uses even one class from another component, a dependency is created between them. If the used component has other classes which the using component doesn’t depend on. Then any change in those classes would force using component to have changes as well.

So, when we depend on a component we need to be sure we are using all the classes in that component. It means, we want to keep together the classes that are inseparable (impossible to depend on one and not on others) in to one component.

Tension diagram for component cohesion

The above diagram shows the tension diagram for component cohesion. The edges of the diagram define the cost of abandoning principle on the opposite vertex.

If an architect focuses on REP and CRP then he will find too many components which change when a new requirement comes. If an architect focuses on CRP and CCP, then he will find he has too many components which are hard to reuse. If an architect focuses on REP and CCP then he will find he has components which have very frequent releases.

A good architect will need to find a position in the triangle which meets the concerns of the current development team, but would also be aware that those concerns will change over time.

For example, when I started working recently on a new project which is rearchitecting current system, our focus initially has been on CCP. We have many components which have classes that change together. At the same time, we have many classes which are reusable together, but currently they are in different components. But as the project matures, things have been changing and we are moving more towards REP.

In conclusion, we need to start grouping classes together into components, we must consider opposing forces involved in reusability and develop-ability. And also acknowledge, that partitioning that is relevant today might not be relevant in future, but would keep on evolving.

Thanks for stopping by! I hope this gives a good preview into component cohesion. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 12 | Components

April 29th, 2023
Components are smallest units of deployment. In java, they are jar files. In ruby, they are gem files and so on.

This chapter mainly focuses on history of components, how they came into existence in the software world.

Starting from the earliest –
1. At first, programmers used to write their programs starting the the physical address where they would be stored in memory. Programs were not relocatable. Programmers would include the source code of library functions with the application code. This resulted in longer load time if programs were big. And eventually this approach failed for very big programs.
2. Relocatable binaries came next to solve this problem. Compiler was changed to output binaries which included function names as metadata. These binaries also, included the address to be loaded and other flags. All this information was then given to loader. Loader would link the function names to place where it has loaded them. Now, programmers can load only the required functions using loader
3. The above approach worked well for small systems. As the number of libraries increase, the time taken by these linking loaders increased. And so linking and loading were separated. Programmers put the linking part into linker. The output of linker was link relocatable file that a relocating loader can quickly load. But still the loading time couldn’t be reduced.
4. As storage optimized, disk became short and fast, RAM became fast and efficient, time spent linking and loading application began to shrink too fast. Next came .jar files, and applications where multiple .jar files can be loaded and linked in few seconds. This was era of component plugin architecture. Here, say you want to pin photos on google chrome, just create an extension/plugin and add it to chrome and have it working.
These dynamically linked files are called the components of our architecture.

Thanks for stopping by! I hope this gives a good preview into components. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 11 | DIP | Dependency Inversion Principle

April 22nd, 2023
So far we have gone through Single Responsibility Principle, Open Closed Principle , Liskov Substitution Principle, Interface Segregation Principle which cover four SOLID principles. In this post, we will go through D ie Dependency Inversion Principle.

DIP says that the most stable systems are those in which source code dependencies refer to abstractions and not to concretions.

Dependency inversion principle cannot be followed as rule because in reality we have to depend on concrete implementations like operating systems, platforms, String in Java, etc. The dependencies like these which are stable and very unlikely to change are excluded from this principle.

The dependencies that are volatile, that are still developing, that can change, we should be depending on their interfaces and not on concrete implementations.

Stable Abstractions

Stable architectures are those that avoid depending on volatile concretions and that favor the use of stable abstract interfaces. They follow following rules –
1. Don’t refer to volatile concrete classes
2. Don’t derive from volatile concrete classes
3. Don’t override concrete functions – concrete functions have dependencies, when you override them, you inherit these dependencies. So ideally we should make functions abstract and create multiple functions.
4. Never mention the name of anything concrete and volatile
Thanks for stopping by! I hope this gives a good preview into DIP. Eager to hear your thoughts and chat, please leave comments below and we can discuss.

Category: Clean Architecture

Clean Architecture – Chapter 14 | Component Coupling | SAP | The Stable Abstractions Principle

Measuring Abstraction

The Main Sequence

The Zone of Pain

The Zone of Uselessness

Main Sequence

Distance from the main sequence

Clean Architecture – Chapter 14 | Component Coupling | SDP | The Stable Dependencies Principle

What is a stable component?

Stability Metrics

Clean Architecture – Chapter 14 | Component Coupling | The Acyclic Dependency Principle

The Weekly Build

Dependency Cycles elimination

Top Down Design

Clean Architecture – Chapter 13 | Component Cohesion

The Reuse/Release Equivalence Principle

The Common Closure Principle

The Common Reuse Principle

Tension diagram for component cohesion

Clean Architecture – Chapter 12 | Components

Clean Architecture – Chapter 11 | DIP | Dependency Inversion Principle

Stable Abstractions