Building Microservice Applications Using SOLID Principles

In this post, we’re diving into the application of design patterns to demonstrate the SOLID principles within the context of a todo microservice application. Adhering to the Single Responsibility Principle, we dissect an application into three primary layers: the application layer, the business layer, and the data layer. The SOLID principles guide the creation and interaction among these layers to forge a scalable, maintainable, and testable microservice application.

Robert Martin, in Clean Code, advises delaying implementation details as long as feasible. But what does this mean for our microservice application? It suggests postponing the implementation of API and data layers. The rationale is that the optimal types of APIs or databases for your business layer might not be immediately apparent. Have you ever encountered bizarre decisions in a legacy project that were dictated by the database schema? Or, while bootstrapping an application, did you frequently adjust the database schema to align with evolving business logic? Perhaps you’ve sought a quick setup without a comprehensive database configuration, or later realized that GraphQL was a superior choice over REST. Postponing these decisions allows your core business logic to shape the right choices later on.

Consider a simple todo application. At its heart, the business logic encompasses creating, retrieving, updating, and deleting todo items. We term this core functionality the “service” of our microservice. Starting with retrieving todos:

class TodoService:
    def get_todos(self):
        session = get_db_session()
        todos = session.get_todos()
        return {"todos": todos}

This straightforward approach, however, mixes data layer responsibilities with the business layer, leading to several drawbacks:

• Changing the database or library necessitates modifications throughout the business layer.
• The choice of data layers for local development and testing becomes limited.

A more sophisticated design employs the Interface Segregation Principle to mediate between the business and data layers. The business layer, forming our microservice’s nucleus, defines an interface for data interaction, which the data layer implements. Below is how our revised example might look:

class DataSession:
    '''The data layer'''
    def __init__(self):
        self.session = get_db_session()

    def exec(self, query):
        self.session.exec(query)

class TodoRepository:
    '''Interface between layers'''
    def __init__(self, data_session):
        self.data_session = data_session

    def get(self):
        return self.data_session.exec('get_todos')

class TodoService:
    '''The business layer'''
    def __init__(self, todo_repository):
        self.todo_repository = todo_repository

    def get_todos(self):
        todos = self.todo_repository.get()
        return todos

This structure accomplishes two main objectives. First, it implements dependency injection to supply the necessary data retrieval mechanism. This flexibility allows varying todo_repository implementations across environments—e.g., SQLite for local development, file-based for testing, and a comprehensive database for production. Second, it adopts the repository design pattern to facilitate the segregation between data and business layers. This intermediary layer supports extending functionality without affecting the other layer, aligning with the Open/Closed Principle.

Integrating the business and data layers, the application layer decides on data retrieval and utilization. During testing, API logic is replaced with test cases, demonstrating how a TestDataSession can mock the data layer without necessitating changes elsewhere.

@app.get("/todo")
def get_todo():
    data_session = DataSession()
    todo_repository = TodoRepository(data_session)
    todo_service = TodoService(todo_repository)
    todos = todo_service.get_todos()
    return { "todos": todos }

class TestDataSession:
    def exec(self, query):
        return []

def test_get_todo():
    data_session = TestDataSession()
    todo_repository = TodoRepository(data_session)
    todo_service = TodoService(todo_repository)
    todos = todo_service.get_todos()
    # assert todos object

While the architecture might seem excessive for a basic application, its scalability and testability are its strengths. Future integrations or database changes necessitate modifications only within their respective layers, underscoring the durability and flexibility offered by adhering to SOLID principles.