Architecture Patterns with Python

Introduction

We’ve found that many developers, when asked to design a new system, will immediately start to build a database schema, with the object model treated as an afterthought. This is where it all starts to go wrong. Instead, behavior should come first and drive our storage requirements. After all, our customers don’t care about the data model. They care about what the system does; otherwise they’d use a spreadsheet.

The first part of the book looks at how to build a rich object model through TDD (in [chapter_01_domain_model|chapter_01_domain_model]), and then we’ll show how to keep that model decoupled from technical concerns. We show how to build persistence-ignorant code and how to create stable APIs around our domain so that we can refactor aggressively.

To do that, we present four key design patterns:

|500

|400
Three layered architecture

Chapter 1. Domain Modeling

Domain modeling: This is the part of your code closest to the business, the most likely to change, and where you deliver the most value to the company. Make it easy to understand and modify.
Distinguish entities from value objects: A value object is defined by its attributes. It’s usually best implemented as an immutable type. If you change an attribute on a Value Object, it represents a different object. In contrast, an entity has characteristics that may vary over time and will remain the same entity. Defining what uniquely identifies an entity (usually some name or reference field) is essential.
Not everything has to be an object: Python is a multiparadigm language, so let the ‚Äúverbs‚ÄĚ in your code be functions. For every¬†FooManager,¬†BarBuilder, or¬†BazFactory, there‚Äôs often a more expressive and readable¬†manage_foo(),¬†build_bar(), or¬†get_baz()¬†waiting to happen.

Chapter 2. Repository Pattern

|800

Repository pattern, a simplifying abstraction over data storage, allowing us to decouple our model layer from the data layer. We’ll present a concrete example of how this simplifying abstraction makes our system more testable by hiding the complexities of the database.

Repository Design Pattern: Simplifying Data Access

Below is the step-by-step explanation of the Repository Design Pattern

Advantages of Repository Design Pattern

Disadvantages of Repository Design Pattern

Use Cases for Repository Design Pattern

Summary

In essence, the Repository Design Pattern is a crucial framework in software development. It neatly organizes data access logic, separating it from the core application. This separation makes code more reusable, maintainable, and easier to test.

By clearly dividing the application and data storage, the pattern allows developers to focus on the main logic without worrying about intricate storage details. Its adaptability enables smooth transitions between data sources and supports efficient testing by creating simulated data repositories.

source: https://www.geeksforgeeks.org/repository-design-pattern/

Chapter 3. A Brief Interlude: On Coupling and Abstractions

Thoughts ūü§Ē by Soumendra Kumar Sahoo is licensed under CC BY 4.0