Software architecture is only as service-oriented as its most monolithic component.

ORM is a good servant but a bad master. The object-relational impedance mismatch is still there and as dangerous as ever.

How to manage breaking changes elegantly and get rid of version IDs for good by being nice to your clients.

It is unfortunate that monolith has become a dirty word. In fact, a physical monolith is typically the right thing to do. Pure evil is monolithic thinking.

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?

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.

One reason I really like the serverless architecture approach is being pretty selfish: one has to care only about what matters - the code.