Self-contained Systems (SCS)
An architectural approach that separates a larger system’s functionality into many independent, collaborating systems.
Created by 
. Driven by the community.
Characteristics
Autonomous
Each SCS is an autonomous web application. For the SCS’s domain, all data, the logic to process that data and all code to render the web interface is contained within the SCS. An SCS can fulfill its primary use cases on its own, without having to rely on other systems being available.
One Team
Each SCS is owned by one team. This does not necessarily mean that only one team can change the code, but the owning team has the final say on what goes into the code base, for example by merging pull-requests.
Asynchronous Dependencies
Communication with other SCSs or 3rd party systems is asynchronous wherever possible. Specifically, other SCSs or external systems should not be accessed synchronously within the SCS's own request/response cycle. This decouples the systems, reduces the effects of failure, and thus supports autonomy. The goal is decoupling concerning time: An SCS should work even if other SCSs are temporarily offline. This can be achieved even if the communication on the technical level is synchronous, e.g. by replicating data or buffering requests.
Service API is Optional
An SCS can have an optional service API. Because the SCS has its own web UI, it can interact with the user — without going through a UI service. However, an API for mobile clients or for other SCSs might still be useful.
Own Data & Logic
Each SCS must include data and logic. To really implement any meaningful features both are needed. An SCS should implement features by itself and must therefore include both.
Own UI
An SCS must make its features usable to end-users via its own UI. Therefore the SCS should have no shared UI with other SCSs. SCSs might still have links to each other. However, asynchronous integration means that the SCS should still work even if the UI of another SCS is not available.
No Shared Business Logic
To avoid tight coupling an SCS should share no business code with other SCSs. It might be fine to create a pull-request for an SCS or use common libraries, e.g. database drivers or oAuth clients.
Hardly Shared Infrastructure
To make SCSs more robust and improve decoupling shared infrastructure can be minimized. E.g. a shared database make fail safeness and scalability of the SCSs depend on the central database. However, due to e.g. costs a shared database with separate schemas or data models per SCS can be a valid alternative.
The Idea
A monolith contains numerous things inside of a single system …
Various Domains
User Interface
Business Logic
Persistence
… as well as a lot of modules, components, frameworks and libraries.
With all these layers in one place, a monolith tends to grow...
... and to grow.
If you cut a monolithic system along its very domains …
… and wrap every domain in a separate, replaceable web application …
… then that application can be referred to as a self-contained system (SCS).
On its outside, an SCS is a decentralized unit that is communicating with other systems via RESTful HTTP or lightweight messaging.
Therefore, self-contained systems can be individually developed for different platforms.
An SCS contains its own user interface, specific business logic and separate data storage .
In addition to a web interface, a self-contained system can also provide an optional API.
The business logic part solely addresses problems that occur within its core domain. This logic is shared with other systems only through a well defined interface.
The business logic may consist of microservices to solve domain specific problems.
Each SCS brings its own data storage and with it redundant data depending on the context and domain.
These redundancies are tolerable as long as the sovereignty of data by its owning system is not undermined.
This enables polyglot persistence, implying a database can be selected to solve a domain specific problem, rather than to fulfil a technical urge.
Within a self-contained system, a variety of technical decisions can be made independently of other systems, such as choices regarding programming language, frameworks, tooling, or workflow.
The manageable domain specific scope enables the development, operation, and maintenance of an SCS by a single team.
Self-contained systems should be integrated via their web interfaces to minimize coupling to other systems.
Therefore, simple hyperlinks can be used to navigate between systems.
Redirection can be used to ensure navigation works in both directions.
Hyperlinks can also facilitate the dynamic inclusion of content served by another application into the web interface of a self-contained system.
To further minimize coupling to other systems, synchronous remote calls inside the business logic should be avoided.
Instead, remote API calls should be handled asynchronously to minimize dependencies and prevent error cascades.
This implies that, depending on the desired rate of updates, the data model’s consistency guarantees may be relaxed.
An integrated system of systems like this has many benefits.
Overall, resilience is improved through loosely coupled, replaceable systems.
Some systems can be individually scaled to serve varying demands.
It is not necessary to perform a risky big bang release to migrate an outdated, monolithic system …
… into a system of systems.
An evolutionary modernization of a large and complex system can be done by …
… migrating in small, manageable steps and by that minimizing the risk of failure.
In reality a system of systems consists of individually developed software and standard products.
A product that fits well into a system of systems can be selected based on the following aspects: it should solve a defined set of tasks and provide the same integration mechanisms that a self-contained system offers.
This ensures that products can be replaced safely …
… by other products once their lifetime has ended.
If a product with such integration mechanisms cannot be found, it should at least be possible to extend that product with uniform interfaces that integrate smoothly with the rest of the system.
Would you like to use this content?
Sure, SCS is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
Would you like to have the idea in slide deck format? There you go:
English: PDF, Keynote, PowerPoint, OpenDocument
German: PDF, Keynote, PowerPoint, OpenDocument
You have got comments, questions, or suggestions?
Checkout the FAQ or create an issue.
Contribute on Github.
Find us on X (Twitter)