Object Oriented Paradigm

The paradigm’s roots started in the 1960s and became dominant during the 1990s. Although it is not exactly an architectural paradigm, it is used as a basic organization of components. The Object Oriented Paradigm basically states that everything is an object; data is contained in fields, and code is run with methods that read and manipulate the data. Objects encapsulate and abstract data and relationships using design patterns, which are reusable solutions to common programming problems. To keep objects under control, it is recommended to follow SOLID principles. Eventually, an application is created by weaving objects that refer to other objects for data and functionality.

Domain Driven Design

When software became more complex, a need for simplicity became more apparent. Thus, the domain-driven design has arisen, based on the premise that code objects should represent the business domain. This helped a generation of developers understand the business. However, when businesses grow, their needs usually change and overlap, so writing software that way becomes harder to maintain since it’s less flexible than other options.

Service Oriented Architecture

By the late 1990s, there was a growing need for distributed systems. Therefore, the service-oriented architecture was created to address issues of scale, security, integration, and reusability, where applications were broken down into smaller business activities and allowed flexibility in integrating even outside services. Eventually, it was inherited by microservices due to the infrastructure of the time. A lack of standardized and slow RPC exacerbated issues such as complexity, service discovery, service management, and security.

Microservices

In the early 2000s, when monoliths and Service-Oriented Architecture dominated, a need for smaller, more maintainable options arose. The realization that most of the software is actually a composition of smaller bits of code became apparent, and so it became a buzzword. Since microservices do offer a more straightforward paradigm where many development teams work disconnected from each other until the moment of integration, working this way can speed development. Yet, similarly to monoliths and service-oriented architecture, writing extensive systems using microservices can become a monster to be tamed because of deployment, monitoring, and integration issues. Docker and Kubernetes have become mainstream tools to cope with some of these issues while introducing their own complexity, which has become more or less the standard.

The IDesign Method

Learning from the drawbacks of domain-driven design, Juval Lowy’s IDesign method aspired to solve the software architecture issues and make a more flexible paradigm that can grow and change with businesses. The central premise of IDesign was that business objects are less important than what they do, such that every dependency that is tightly integrated and might change should be isolated from the architecture and the decisions that are made based on it. It was called Volatility-Based-Decomposition, in which, in essence, every component in the system can be an accessor to something, an engine that drives one or more accessors, and managers coordinate the integration between these parts; there’s a large community around these ideas.

Residuality Theory

One of the major issues with modern software is its inflexibility to business needs, which conflicts with the business jungle that can change significantly during a short period. Barry O’Reilly’s Residuality Theory aims to explain how successful businesses have achieved that goal. He concluded that for a system to survive and extend the business needs, it needs to be ready for such changes; and that the best way to achieve this is by analyzing the system for stressors – be it changes, an unexpected competitor, a supplier closing shop, and even war. By analyzing the system’s behavior in each of these stressors and modifying the architecture to account for it, the architecture seems to change very little after a few iterations, leaving a system better suited to cope with unknown stressors and changes.

Photo by Christina Morillo on Pexels