//Artefact:SoftwareBundle/com/sphenon/products/EMOS (5.1) - Working/Architecture - Solution Architecture
Overview
Architecture of an EM/OS Software Solution
The production of Software with EM/OS is based on a variety of
input information and can be configured to a large degree. This
includes the choosen target architecture, i.e. the selection
of produced components as well as the blueprints and templates
of these components themselves.
For this reason, there obviously is no such thing as
"The One and Only Solution Architecture".
Nevertheless, a large body of configurations has been developed to
produce a range of very versatile components, based on advanced
architectural principles, as illustrated in the following.
Horizontal Layering
A fully operational full stack component comprises all horizontal functionality
from database, logic, and user interface up to service interfaces. Such components
in itself are well structured and show a high degree of adaptability to various
environments. Prominent examples of such environmental technologies are different
user interface media, different databases and different service types.
All these layers are optional, e.g. there can be user interface free service
components, database free components operating on remote or legacy data
providers, or pure user interface components presenting functionality that
is implemented elsewhere.
Moreover, be aware that this layering does not imply that such a component
shows monolithic characteristics - to the contrary, it is well possible to
implement single service calls in tiny nanoservices this way.
The following diagram shows these horizontal layers arranged in a way
that illustrates roughly their interplay.
The purpose of the individual layers is as follows.
- Specific Media Frontends
- Frontend Technology Binding
- AbstractLayoutFrontend
- Virtual User Interface
- Media Equipment
- Interactors
- Application Client Interface
- Specific Service Frameworks
- Service Technology Bindings
- Domain Interaction Layer
- Domain Core Layer
- Coordinator
- Transparent State Management
- Storage Technology Bindings
- Specific Persistency Backends
- Database
Vertical Slicing
As mentioned above, the horizontal layering does not affect the choice which
vertical (business/domain) functionality is contained in a single imeplementation
unit (component). With the EM/OS approach, it is
well possible to specify the domain and business system properties in a single,
clean, and comprehensible model, and distribute this model on different arrangements
of implementation units, whereas the choice of this distribution is independent
of the model and can be changed lateron if desired.
As an example, the following diagram shows how an integrated model is projected
on a (cleanly organised) monolith on the left hand side, while alternatively
the parts of this same model are projected on two microservices on the right
hand side. To allow communication between these microservices, they share a
certain part of the model, which thereby specifies the details of the
interface and channel between these microservices.
Moreover, the specification model can, but does not need to exist as a unified,
holistic model. E.g., the different model parts may be maintained within two
different companies, and only the shared part needs to be exchanged to define
the inter-service communication.