There are many different views on what is summarized by the term architecture. First we introduce the key principles and architecture principles of devonfw. Then we go into details of the the architecture of an application.
For devonfw we follow these fundamental key principles for all decisions about architecture, design, or choosing standards, libraries, and frameworks:
-
KISS
Keep it small and simple -
Open
Commitment to open standards and solutions (no required dependencies to commercial or vendor-specific standards or solutions) -
Patterns
We concentrate on providing patterns, best-practices and examples rather than writing framework code. -
Solid
We pick solutions that are established and have been proven to be solid and robust in real-live (business) projects.
Additionally we define the following principles that our architecture is based on:
-
Component Oriented Design
We follow a strictly component oriented design to address the following sub-principles:-
Reusability and avoiding redundant code
-
Information Hiding via component API and its exchangeable implementation treated as secret.
-
Design by Contract for self-contained, descriptive, and stable component APIs.
-
Layering as well as separation of business logic from technical code for better maintenance.
-
Data Sovereignty (and high cohesion with low coupling) says that a component is responsible for its data and changes to this data shall only happen via the component. Otherwise maintenance problems will arise to ensure that data remains consistent. Therefore interfaces of a component that may be used by other components are designed call-by-value and not call-by-reference.
-
Homogeneity
Solve similar problems in similar ways and establish a uniform code-style.
For the architecture of an application we distinguish the following views:
-
The Business Architecture describes an application from the business perspective. It divides the application into business components and with full abstraction of technical aspects.
-
The Technical Architecture describes an application from the technical implementation perspective. It divides the application into technical layers and defines which technical products and frameworks are used to support these layers.
-
The Infrastructure Architecture describes an application from the operational infrastructure perspective. It defines the nodes used to run the application including clustering, load-balancing and networking. This view is not explored further in this guide.
The business architecture divides the application into business components. A business component has a well-defined responsibility that it encapsulates. All aspects related to that responsibility have to be implemented within that business component. Further the business architecture defines the dependencies between the business components. These dependencies need to be free of cycles. A business component exports his functionality via well-defined interfaces as a self-contained API. A business component may use another business component via its API and compliant with the dependencies defined by the business architecture.
As the business domain and logic of an application can be totally different, the devonfw can not define a standardized business architecture. Depending on the business domain it has to be defined from scratch or from a domain reference architecture template. For very small systems it may be suitable to define just a single business component containing all the code.
The technical architecture divides the application into technical layers based on the multilayered architecture. A layer is a unit of code with the same category such as service or presentation logic. A layer is therefore often supported by a technical framework. Each business component can therefore be split into component parts for each layer. However, a business component may not have component parts for every layer (e.g. only a presentation part that utilized logic from other components).
An overview of the technical reference architecture of the devonfw is given by figure "Technical Reference Architecture". It defines the following layers visualized as horizontal boxes:
-
client layer for the front-end (GUI).
-
service layer for the services used to expose functionality of the back-end to the client or other consumers.
-
batch layer for exposing functionality in batch-processes (e.g. mass imports).
-
logic layer for the business logic.
-
data-access layer for the data access (esp. persistence).
Also you can see the (business) components as vertical boxes (e.g. A and X) and how they are composed out of component parts each one assigned to one of the technical layers.
Further, there are technical components for cross-cutting aspects grouped by the gray box on the left. Here is a complete list:
Please click on the architecture image to open it as SVG and click on the layers and cross-cutting topics to open the according documentation guide.
We reflect this architecture in our code as described in our coding conventions allowing a traceability of business components, use-cases, layers, etc. into the code and giving developers a sound orientation within the project.
Further, the architecture diagram shows the allowed dependencies illustrated by the dark green connectors.
Within a business component a component part can call the next component part on the layer directly below via a dependency on its API (vertical connectors).
While this is natural and obvious it is generally forbidden to have dependencies upwards the layers
or to skip a layer by a direct dependency on a component part two or more layers below.
The general dependencies allowed between business components are defined by the business architecture.
In our reference architecture diagram we assume that the business component A1 is allowed to depend
on component A2. Therefore a use-case within the logic component part of A1 is allowed to call a
use-case from A2 via a dependency on the component API. The same applies for dialogs on the client layer.
This is illustrated by the horizontal connectors. Please note that persistence entities are part of the API of the data-access component part so only the logic component part of the same
business component may depend on them.
The technical architecture has to address non-functional requirements:
-
scalability
is established by keeping state in the client and making the server state-less (except for login session). Via load-balancers new server nodes can be added to improve performance (horizontal scaling). -
availability and reliability
are addressed by clustering with redundant nodes avoiding any single-point-of failure. If one node fails the system is still available. Further the software has to be robust so there are no dead-locks or other bad effects that can make the system unavailable or not reliable. -
security
is archived in the devonfw by the right templates and best-practices that avoid vulnerabilities. See security guidelines for further details. -
performance
is obtained by choosing the right products and proper configurations. While the actual implementation of the application matters for performance a proper design is important as it is the key to allow performance-optimizations (see e.g. caching).
The technology stack of the devonfw is illustrated by the following table.
| Topic | Detail | Standard | Suggested implementation |
|---|---|---|---|
runtime |
language & VM |
Java |
Oracle JDK |
runtime |
servlet-container |
JEE |
|
dependency injection |
|||
framework |
- |
||
OR-mapper |
|||
framework |
|||
framework |
|||
framework |
|||
Authentication & Authorization |
|||
framework |
|||
HTTP Bridge |
HTTP & JSON |
||
framework |