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 - perfer easy solutions, do not over-engineer. -
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. -
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 APIs 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 each programming language addressed by devonfw we therefore define clear coding-conventions.