Sebastian Buczyński - Implementing The Clean Architecture

This book is meant to be a supplement to Robert C. Martins Clean Architecture: A Craftsmans Guide to Software Structure and Design . It is focused on practical aspects of applying the Clean Architecture in IT projects. I find a scarcity of good - quality implementation examples unsatisfactory. Since I used this approach successfully in a few projects, I believe I have plenty of illuminating insights to share with the community.

At the same time, I came across some limitations which I had to overcome. Sometimes the cure was to use other technique (such as CQRS - Command Query Responsibility Segregation ), sometimes it would be better not to use the Clean Architecture at all.

In short, this book was conceived to share all experience me and my colleagues got during the implementation of the Clean Architecture.

World of Python is a magical, enchanting place. Imagine you are to write some boilerplate code needed to implement an actual feature. Virtually every time you are about to fall under such an evil spell, you can break it by casting a counter-spell:

pip install

Ease of using this command combined with libraries profusion enables everyone, including apprentices of sorcery, to solve seemingly complex problems with a little mana expense. Nowadays, wizardry called software development can be picked up and practised almost effortlessly without knowing its arcana, though nature of the magic itself has not changed at all. This creates an illusion that knowledge about principles and patterns is no longer needed. Although entry point is lowered, deluded sorcery apprentices are far from being enlightened.

Literally every tool python developers use daily is an implementation of long-know (more than decades) and an extensively described pattern of some sort. Django ORM? It is an example of Active Record pattern implementation, widely known thanks to Ruby On Rails which follows the same pattern. For example, it was described in Martin Fowler's Patterns of Enterprise Application Architecture using these words:

"Its easy to build Active Records, and they are easy to understand. Their primary problem is that they work well only if the Active Record objects correspond directly to the database tables: an isomorphic schema. (...) Another argument against Active Record is the fact that it couples the object design to the database design. This makes it more difficult to refactor either design as a project goes forward.

What about something more sophisticated, like SQLAlchemy's session? It turns out the pattern behind it is called Unit of Work and is described in the same book. Suddenly an impression of magic powering PyPi packages fades away to eventually vanish. Such knowledge is an invaluable help to choose the right tools for the job. At the same time, a tool which solves your most acute problem will cause several lesser ones, yet those ones you can live with. For example, SQLAlchemy's session forces a developer to register any newly created model using add method. Without it, no data will be persisted upon commit. Is the necessity for manual models management worth the trouble, or maybe Django ORM is just ok for this particular project?

The most effective cure for indecisiveness is to stay pragmatic and flexible. In fact, this is what this book is truly about. Even though it explains an exciting approach which highlights the importance of business concerns, it does not conveniently omit drawbacks.

Whenever a new project is started, developers should ask themselves: which approach/framework/library should they use? I may ask in return: What problems would you prefer to have? What issues you have to avoid?