Gain insights into clean architecture using Python. Delve into layered systems, design efficient applications, and integrate web components, error handling, and databases with test-driven development practices.

tarball.tar.gz

POSTGRES_USER

POSTGRES_PASSWORD

POSTGRES_HOSTNAME

APPLICATION_DB

POSTGRES_PORT

POSTGRES_DB

Python Execution

Flask

Flask + Postgres

Python Test

Clean architecture is a software design methodology that separates the processes of an application into discrete steps instead of presenting them as “spaghetti code.” With the versatility of Python, software engineers can build performant, modular applications quickly using the Flask framework.

This course will help you build better applications using the principles of clean architecture. You’ll start with an introduction to data flow in clean systems and learn about the advantages of layered architectures. Next, you’ll learn system components and the connections between application layers. You’ll then design and build a clean system using Python by layering components in guided coding exercises. Finally, you’ll learn how to add functional components for the web, handle errors, and work with external databases using both Postgres and MongoDB. At each step, you’ll use test-driven development practices to ensure robust functionality.

Clean Architecture in Python

# Overview

In every software project, a large part of the code is dedicated to error management. This part of the code has to be infallible. Yet, more often than not, we find that we’ve left out cases that give errors, or we’ve provided a condition that we thought would never fail but does.

In clean architecture, the main process is the creation of use cases and their execution. As we can expect, this is also the main source of errors. So, the use cases layer is where we have to implement error management. This isn’t to say that errors can’t also come from the domain models layer. However, since those models are created by the use cases, the errors that aren’t managed by the models themselves are automatically treated as errors of the use cases.


# Request and Responses

We can divide the error management code into two different sections:
- The first section represents and manages requests—that is, the input data that reaches our use case.
- The second section covers how we return results from the use case through responses or the output data.

These two concepts shouldn’t be confused with HTTP requests and responses, even though there are similarities between them. We are now considering how data is passed to and received from use cases and how errors can be managed. This isn’t related to another possible use of this architecture, which is to expose an HTTP API.


## Request and response objects

Request and response objects are an important part of clean architecture because they transport call parameters, inputs, and results from outside the application into the use cases layer.

More specifically, requests are objects created from incoming API calls. They deal with things like incorrect values, missing parameters, wrong formats, and so on. On the other hand, responses not only have to contain the actual results of the API calls but should also be able to represent error cases and deliver rich information on what happened.

The implementation of request and response objects depends completely on our discretion. Clean architecture says nothing about it. The decision on how to pack and represent data is up to us.


Let’s learn about error management in clean architecture.

Get Started

A Day in the Life of a Clean System

Components of Clean Architecture

A Simple Coding Example

Add a Web Application

Error Management

Integration with a Real External System Postgres

Integration with a Real External System MongoDB

Run a Production-ready System

Appendix

Overview of Error Management

Overview