Our software systems are becoming more and more complex, and the demands on architecture and design are constantly increasing. Of course, the program structure should still be comprehensible and flexible, and it must also be possible to maintain the source code well and extend it easily. Sounds quite simple. Unfortunately, many software projects are far away from this and tend rather to the much quoted Big Ball of Mud.

Haven't the S.O.L.I.D. principles been around for a long time? But what did the "I." stand for again? And what was the Liskov substitution principle all about? Through frameworks we actually use many of the principles every day, but often don't know the background (anymore). Therefore, it is time to recall them again and to put their impact on the design and decision making of modern software architectures to the test. We will use examples to discuss the strengths, but also possible risks and trade-offs. And we will look at alternative patterns and principles. This way you can apply the ideas directly to your projects.