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:

• The Repository pattern, an abstraction over the idea of persistent storage
• The Service Layer pattern to clearly define where our use cases begin and end
• The Unit of Work pattern to provide atomic operations
• The Aggregate pattern to enforce the integrity of our data

Three layered architecture

Chapter 1. Domain Modeling

• Domain is the problem we are trying to solve as a software engineer.
• The domains of an online furniture retailer include purchasing and procurement, product design, or logistics and delivery.
• Most programmers spend their days trying to improve or automate business processes; the domain is the set of activities that those processes support.
• A model maps a process or phenomenon that captures a valuable property.
• The domain model is the mental map that business owners have of their businesses. All business people have these mental maps—how humans think about complex processes.

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

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

• The Repository Design Pattern is a software design pattern that acts as an intermediary layer between an application’s business logic and data storage.
• Its primary purpose is to provide a structured and standardized way to access, manage, and manipulate data while abstracting the underlying details of data storage technologies.
• This pattern promotes a clear separation of concerns, making software more maintainable, testable, and adaptable to changes in data sources without entangling the core application logic with data access intricacies.
• In essence, the Repository Design Pattern is a blueprint for organizing and simplifying data access, enhancing the efficiency and flexibility of software systems.

Advantages of Repository Design Pattern

• Centralized Data Access: The pattern centralizes and abstracts data access logic, allowing the rest of the application to interact with data through a consistent interface. This simplifies code maintenance by managing all data-related operations in one place.
• Enhanced Testability: Separating data access logic from the business logic facilitates easier unit testing. With a clear interface for data operations, mocking or substituting the repository makes it simpler to test other application parts independently.
• Improve Code Maintainability: The repository design pattern promotes clean code by isolating data access logic. This separation allows developers to make changes or optimize data access without affecting the rest of the application.
• Reusability and Extensibility: By adhering to the repository contract, multiple parts of the application can reuse the same data access methods. This allows for the easy addition of new data sources or technologies without having to change the application's main logic.

Disadvantages of Repository Design Pattern

• Overhead for Simple Applications: Implementing the repository design pattern might introduce unnecessary complexity in smaller or straightforward applications. In such cases, the added layers of abstraction might be more cumbersome than beneficial.
• Learning Curve and Development Time: Adopting the repository design pattern might require additional development time, as it involves creating interfaces, defining contracts, and implementing concrete repository classes. This learning curve could impact project timelines.
• Potential Abstraction Leaks: In some cases, the repository design pattern might leak underlying implementation details to higher layers, making the abstraction less effective. This can happen if the repository needs to cater to complex queries or operations.

Use Cases for Repository Design Pattern

• Web Applications: Repositories are commonly used in web applications to manage data access to databases. They abstract the interaction with the database and make switching to a different database system easier.
• APIs and Services: The repository Pattern can help keep data access clean and organized when building APIs or microservices. It enables multiple services to interact with data consistently.
• Large and Complex Systems: For large, complex systems where data access logic can become tangled and messy, the Repository Pattern offers a tidy way to handle data access. This makes the code easier to maintain and manage.
• Testing Environments: It’s valuable in testing environments where you want to isolate data access for testing purposes. Mock repositories can be created to simulate data access without modifying the actual data source.
• Data Migration: The repository pattern allows for a smoother transition when migrating data from one database to another. You can replace the repository’s implementation to work with the new data source while keeping the rest of the application intact.

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