The principles for good software design apply on all levels. In the same way that we want to write readable code, and for that we need to mind the intention revealing degree of the code, the architecture also has to express the intent of the problem it is trying to solve.

All these ideas are interconnected. The same intention revealing that ensures our architecture is defined in terms of the domain problem also leads us to abstract details as much as possible, create layers of abstraction, invert dependencies, and separate concerns.

When it comes to reusing code, Python packages are a great and flexible alternative. Criteria, such as cohesion and the single responsibility principle (SRP), are the most important considerations when deciding to create a package. In line with having components with cohesion and few responsibilities, the concept of microservices comes into play, and for that, we have seen how a service can be deployed in a Docker container starting from a packaged Python application.

As with everything in software engineering, there are limitations, and there are exceptions. It will not always be possible to abstract things as much as we would like to or to completely isolate dependencies. Sometimes, it will just not be possible (or practical) to comply with the principles explained here in the book. But that is probably the best piece of advice the reader should take from the book—they are just principles, not laws. If it's not possible, or practical, to abstract from a framework, it should not be a problem. Remember what has been quoted from the zen of Python itself, throughout the book—practicality beats purity.