//Artefact:SoftwareBundle/com/sphenon/products/EMOS (5.1) - Working/Architecture - Solution Architecture


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.
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.