How do Java Records fit to the object-oriented design?

Interfaces are good stuff. Does that mean the more the better?

Configuration is part of the application API, so the same rules apply to it: no leak of implementation detail.

Defining service boundaries is hard. Let's bring some colors and make it fun!

Which purpose has a Repository? To which layer does it belong to? And how to implement it correctly?

Collection, List and Set are terms very familiar to developers but hardly used by business experts. Therefore, they should not be part of the domain (API).

There are situations where events and commands seem to be a good solution for a problem. Where to use events and where are commands the best fit?

Multitenancy was and still is a very popular and successful architectural pattern of the last decades. But, that is likely to change with the advent of cloud computing.

From time to time I attend discussions about OOP. Every time someone comes up with the argument of dealing with persistence. The typical question can be reduced to “should an object persist itself or rather be persisted?” I believe the question is fundamentally wrong.

There are a lot of articles about the SOLID principles. But usually a different example for a particular principle is to be found. Instead, would it be nice to demonstrate all of them on a single code snippet?