add "ISOLATION" to design/architecture principles (as part of Modularization or SoC)

[gernotstarke]

it's similar to modularity and separation-of-concerns (SoC), but not completely identical. (e.g. the "I" in ACID).

therefore, let's add it (maybe as amendmend to coupling) so our discussion of principles becomes a little more complete.

Sources:

• https://insights.sei.cmu.edu/blog/software-isolation-why-it-matters-to-software-evolution-and-why-everybody-puts-it-off/
• Pacheco/Sgo: Principles of SWA Modernization, bpb-Press 2024
• https://insights.sei.cmu.edu/blog/software-isolation-why-it-matters-to-software-evolution-and-why-everybody-puts-it-off/
• Richards/Ford: Fundamentals of Software Architecture, OReilly.

[sippsack]

I must confess, I haven't read the sources yet. But for me isolation in ACID is isolation of (database) transactions. So, we don't talk about ACID here, isn't it?

[gernotstarke]

Right, it is NOT about ACID, but about ISOLATING components from each other, isolating data models from their usage... in general: isolation as a design/architecture principle.

ACID is one example of applied-isolation.

[mikesperber]

If we're going to add it, we need to do some work on specifying what we mean. (The SEI post is a mushy corporate-speak mess, as per usual for them.)

[ulibecker]

I would not add it. I do not see a concise definition in the SEI article, and I see a lot of overlap with loose coupling. In the fundamentals of software architecture book, it doesn't show up in the index (although I see they use the term a lot). I see a lot of potential to confuse participants, and I do not see the value this would add.

[gernotstarke]

The principles show lots of overlap anyway... modularization, loose coupling, high cohesion, separation-of-concern... all suffer from overlap.

Several authors and sources discuss the concept of "isolation" in software architecture. Some key references and ideas related to isolation in software architecture:

• Eric Evans, in his book "Domain-Driven Design," emphasizes the importance of isolating the domain logic from other parts of the system. He proposes concepts like "Bounded Contexts" and "Anti-Corruption Layers" to achieve isolation between different parts of a complex system.
• The layered architecture pattern, as described in "Software Architecture Patterns" by Mark Richards, inherently promotes isolation between different layers of an application. Each layer is designed to be closed, meaning requests must pass through the layer below it, thus isolating concerns.
• The microservices architecture pattern, also discussed by Mark Richards, takes isolation to a higher level by deploying components as separate units. This approach enhances scalability and provides a high degree of decoupling within the application.
• The concept of "layers of isolation" is a key feature of the layered architecture pattern. As explained in O'Reilly's "Software Architecture Patterns," this concept means that changes made in one layer generally don't impact components in other layers, isolating the change to components within that layer.
• The "bulkhead" pattern, inspired by ship design, is a resilience pattern that enables developers to design systems with multiple, independent subsystems and services running in their own private machines or containers. This pattern limits the effect of a failure on neighboring processes and allows teams to examine failures in isolation.

Other opinions: In or Out?

[ulibecker]

Yeah, no doubt about that. In embedded systems this is also relevant with regards to freedom from interference. I absolutely see this as relevant in specific ways for several advanced modules, e.g. FLEX, IMPROVE, EMBEDDED. I just doubt that it helps us here as a general principle, especially since the curriculum is already quite packed.

[gernotstarke]

ok - seems we don't get a majority pro, so I set this issue to "wontfix" for now.