Sof3-

C3.2
S1 Dependency Inversion Principle (1)
• Blocks of higher levels should not depend on blocks of lower levels; both should depend on abstractions
• Abstractions should not depend on details, details should depend on abstractions
S2

Disadvantages if this principle is violated:

• Business Logic cannot be exchanged without customizing the user interface
• Both classes cannot be compiled independently of each other. (The same would apply if it were not
about classes but larger components)
Higher coupling
S3

With dependency injection, dependencies are transferred (injected) from the outside.
The configurator / assembler creates and
The connection "worries":
• Constructor injection
Setter injection
S5 Dependency Look-Up

• Dependency look-up means that a

block creates its link to another
block at runtime by searching for
this other block via a name or other
properties in a registry at runtime.
• All blocks to be linked must have a
reference to the registry at the
beginning.
• The connection between the
components can be established at
runtime.
• In the example, User Interface can
get a reference to Business Logic via
the registry.
• But both have to know "where" the registry can be reached

S6 Avoid or resolve cyclical dependencies

• Cyclical dependencies complicate the maintainability and changeability of systems and prevent separate
reuse.
• Unfortunately, they cannot always be avoided
S7 Prefer composition over inheritance (1)
• Application of the principle promotes less coupling and leads to more flexible and stable architectures.
• Allows you to change the behavior of classes, modules or systems at runtime.
• Improves testability
• Any inheritance can be replaced by composition.
S10 Other principles
• Root cause analysis
Treating symptoms may bring relief quickly - but in the long run it will cost more effort
Therefore: look under the surface of the problems! (Despite all resistance and the time / project pressure)
• Reflect daily
Without reflection, no improvement, no progress and no learning.
Reflection must be planned in, otherwise it does not take place under the pressure of day-to-day
business.
• Automatic checking of architectural rules & static code analysis
S11 Cognitive psychology as the basis of durable and expandable architecture
• The human brain has acquired mechanisms that help us deal with complex structures.
This should be used so that maintenance and extensions can be carried out efficiently and effectively.
• The three mechanisms that our brains have developed for complex structures are
Chunking
Building hierarchies
 Structure of schemes
S14 Basics of Domain Driven Design
• Domain Driven Design (DDD) is an approach to modeling complex software.
• The modeling is significantly influenced by the technicalities of the application domain to be
implemented.
• The design of the software should be based on a model of the application domain.
• Requires close collaboration between developers and experts.
• DDD is independent of a specific programming language and the chosen process model
S15 Ubiquitous language
• One focus is on the introduction of an ubiquitous language, which should be used in all areas of
software development.
•„A language structured around the domain model and used by all team members to connect all the
activities of the team with the software.“
S16 Components of a domain model
Entities: Objects that are defined not by their properties but by their identity.
Value objects: Objects that are only defined by their properties (are mostly immutable).
Aggregates: Summary of entities and value objects
Associations Relationships between objects of the domain model
Service objects: important functionalities of professionalism
Technical events: Events that cause several actions or changes in the technical objects. Allow modeling of
distributed systems.
Modules: Divide the domain model into technical (not technical!) Components (see cohesion &
coupling).
S17 Event storming
shop-based method to quickly find out what is "happening" in a domain.
>> The business process is "stormed out" as a series of domain events which are denoted as stickies. <<
Method to bring together experts and software developers.
S18 More concepts from DDD
• Context boundaries (BoundedContext)
 Describe the boundaries of each context in several dimensions, e.g. Team assignment, specialist
departments, ...
• Context overview (ContextMap)
Complete overview of all models, their limits and interfaces.
• Anti-corruption layer (AnticorruptionLayer)
Separates the domain model from other models. The "own" model is not directly influenced by changes
in "foreign" models.
DDD includes much more! Only a small section is presented here.