Out-Of-Process Design Vs Aspect-Oriented Programming— Where to apply what?

Both promote high cohesion and low coupling. Both take cross-cutting concerns away from the core business concern. So what's the difference?

Abhinav Kapoor
CodeX
4 min readApr 2, 2023

--

Similarities and Differences between Aspect-Oriented Programming & Out of Process Design. Image Credit — Author

Some time back while I was talking to a seasoned technologist on the subject of out-of-process design, we discussed Aspect-oriented programming too because it intercepts calls & helps achieve high cohesion. And that's the motivation for this write-up to cover the overlaps & the differences.

In the photo above, I’ve tried to show that they are similar in their prime intention of keeping, that is to keep cross-cutting concerns out of the core business logic. But their area of application is different. Let's see this in detail.

Similarities — High Cohesion & Low Coupling

What does this mean?

High Cohesion — It means strongly related things are grouped together in a structure. Usually, when referring to high cohesion, it refers to Functional cohesion. Functional cohesion means grouping things because they all contribute to a single well-defined task.

In a software implementation, it could start at the smallest level — functions. And can grow into classes, assemblies, services & systems.

If all related things are kept together, and not spread all over, it leads to the other desirable trait of manageable software — low coupling (or loose coupling).

Image Credit — https://en.wikipedia.org/wiki/Coupling_(computer_programming)

Low Coupling — Coupling means binding. As shown in the image above, if the binding happens through well-defined connection points with minimal information/assumption about the internals of the other structure then it's loose coupling.

On the other hand, if there is too much coupling, it means the structures are not cohesive and their boundaries need to be reconsidered.

Why are these traits desirable? We want each structure to be only bothered by what is contained in it. This promotes maintainability, by containing the ripple effect of changes, issues, and latency within the cohesive structure.

Concern refers to aspects/features of the software. For example, non-functional concerns can be logging, resilient communication or security. Functional concerns can be formatting numbers/dates as per region.

Cross-cutting concerns (or horizontal concerns) are features which are needed across the program/system.

As I wrote that high cohesion and low coupling can be applied at different levels within software — functions, classes, assemblies, services & systems. This area of application is different between Out-of-process design and Aspect-oriented programming. Let’s see how

Difference — How is High Cohesion & Low Coupling Achieved?

Aspect-Oriented Programming (AOP)

AOP is a programming paradigm to modularize the code of an application with separation of concerns.

  1. AOP makes it possible to encapsulate cross-cutting concerns.
  2. AOP gives mechanisms to invoke these cross-cutting concerns from core concerns in a declarative way.

To make it work, AOP injects the advice from encapsulated cross-cutting concerns into the core/primary concern to produce the final executable. This process is called weaving.

Single Process

The output will be loaded as a single process, targeting a single runtime therefore the choice of technologies has to be compatible with the runtime. For example, it won't be possible to use an AOP tool for java in a .NET application.

Out-of-Process Design

Out-of-Process design, on the other hand, is a higher-level design philosophy which intends to take out the infrastructure concerns (& secondary concerns) & overarching concerns from the main application process into separate processes.

These processes may be distributed, or on the same node or within the same pod as sidecar containers.

Out-of-Process: Stand-alone processes to support the main application process

It brings several benefits at the cost of complexity:

  1. The cross-cutting processes can be in any technology as long as communication with the main application is possible.
  2. Since it’s easier to mix technologies, it’s possible to bring the best-suited tool for each job rather than looking for a good generic solution.
  3. It enables autonomous scaling of the processes.
  4. The cross-cutting process can be updated, or replaced without affecting the main application.

Summary

AOP — Keeps the concern segregated at the code level.

OOPD — Keeps concerns segregated at the process or service level.

Further study & Credits

For more on AOP — https://www.youtube.com/watch?v=71vp0t1e2Xw

Out-of-process design & Side Car Proxies — Why do we need multi-container pods?

How does service mesh use Out of process design -What is Service Mesh? And why do we need it over Kubernetes?

--

--

Abhinav Kapoor
CodeX

Technical Architect | AWS Certified Solutions Architect Professional | Google Cloud Certified - Professional Cloud Architect | Principal Engineer | .NET