[<<back]

The Developer's Diary

The Road Ahead: Recapping Our Architecture

A look back at the clean architecture we've built and a peek at the exciting concepts that lie ahead.

Over the past few posts, we've journeyed through the foundational files of our SpLD assessment application. We've established a clean, decoupled architecture where every component has a clear and distinct purpose. Before we look forward, let's take a moment to recap the structure we've so carefully designed.

Recap of Our Architecture

main.py

The Assembler. Our Composition Root where all application components are instantiated and wired together using Dependency Injection.

config.py

The Secret Keeper. A centralized module for all configuration, safely loading secrets like API keys from the environment and decoupling the app from its deployment details.

app/core/models.py

The Vocabulary. Defines our core Domain Models (Entities and Value Objects) using dataclasses, creating an explicit contract for the data structures our app uses.

app/core/services.py

The Conductor. Orchestrates application use cases, delegating work to the domain models and repositories. It contains application logic but no infrastructure details.

app/data/repository.py

The Bridge. Implements the Repository Pattern, providing an abstraction over the database and isolating the core application from persistence concerns like SQL.

tests/

The Safety Net. Houses our automated test suite, using unit tests with mocks for services and integration tests for the repository to ensure correctness and prevent regressions.

What's Hot Now? Modern Architectural Buzzwords

The architecture we've built is a fantastic starting point, adhering to timeless principles of software design. But the world of software architecture is always evolving. Let's explore some modern patterns that build upon these same principles.

Novice Coder (NC): "This all makes sense. I feel like I have a solid foundation. But I keep hearing terms like 'Hexagonal Architecture', 'CQRS', and 'Event Sourcing' on podcasts. Are those relevant to us?"

Experienced Coder (IC): "Great question! They're not just buzzwords; they're patterns that take our 'separation of concerns' principle even further. In fact, we've accidentally built the foundation for one already. Our architecture is very close to Hexagonal Architecture, also known as 'Ports and Adapters'. Think of our core application (models and services) as the hexagon. The UI and the database are 'adapters' that plug into 'ports'—which are just our abstract interfaces, like the `AbstractRepository`."

NC: "Okay, so Ports and Adapters is just a different name for what we're doing? What about CQRS?"

IC: "CQRS stands for Command Query Responsibility Segregation. It's the idea that the model you use to *write* data can be different from the model you use to *read* it. For our app, saving an assessment is a 'Command'. But what if we need to generate a complex report for a psychologist? That's a 'Query'. The query might need data from multiple tables, formatted in a very specific way. CQRS says it's okay to create a separate, optimized read model for that report instead of trying to force our `Assessment` entity to do everything."

NC: "That makes sense. And Event Sourcing?"

IC: "That one's really interesting for our use case. With Event Sourcing, instead of just saving the *current state* of an assessment, we save a sequence of every single change that ever happened to it as an 'event'. For example: 'AssessmentCreated', 'HypothesisAdded', 'ReportSummaryUpdated'. The current state is just the result of replaying all those events. The big win? You get a perfect, unchangeable audit trail for free, which is incredibly valuable in a clinical context."

These patterns, while advanced, are built on the same foundation of decoupling and clear separation of responsibilities that we've established. By starting with a clean architecture, we've given our SpLD assessment application the ability to grow and adapt, potentially incorporating these powerful ideas as its needs evolve.

Next deep dive [dependency injection]

Next deep dive [java and python - @dependency_injection]