Skip to main content

Strategic Design: System Context & DDD

Architecting an enterprise-grade financial platform from scratch using Domain-Driven Design (DDD) to prevent architectural degradation and manage complex business rules.

TL;DR

Architected a highly scalable microservices ecosystem for real-time financial data processing. Leveraged Domain-Driven Design to identify 15 Bounded Contexts and established robust Context Mapping (using gRPC and NATS) to ensure strict domain isolation and independent deployability.

lzstock-system-context-map

The Challenge & Impact​

  • The Challenge: Financial systems inherently possess deeply complex and overlapping business rules (e.g., Market Data vs. User Portfolios vs. Watchlists). A traditional monolithic database-driven approach inevitably leads to a highly coupled "Big Ball of Mud," where modifying a stock aggregation rule could unintentionally break the user authentication service.
  • The Objective: To establish a strategic architectural blueprint upfront. The goal was to enforce strict domain boundaries, prevent business logic leakage, and design a system topology that conceptually supports future team scaling and isolated deployments.
  • The Impact: Successfully mapped the financial domain into 15 distinct Bounded Contexts. Translated this strategic design into 6 (~2025/12) independent Golang microservices, achieving high cohesion, low coupling, and a resilient foundation ready for distributed cloud environments.

Architecture & Execution​

Tech Stack​

Domain-Driven Design (DDD), Microservices Architecture, Context Mapping, gRPC, NATS (Event-Driven)

1. Strategic Modeling & Bounded Contexts​

To establish a robust foundation, I implemented a top-down strategic design approach to identify Core, Supporting, and Generic subdomains, eventually distilling them into 15 Bounded Contexts.

Key context isolations include:

  • BC1 (Dashboard & Watchlist): Aggregates tailored financial insights and user-specific tracking.
  • BC3 (Company Data): The core domain handling SEC financial data standardization and internationalization (i18n).
  • BC10 (Data Pipeline): The ingestion and transformation engine (an architectural evolution of my 2020 Python ETL project).
  • BC11 (Market Monitoring): An event-driven engine feeding real-time market events to downstream systems.
  • BC13 (Auth & Session): Centralized investor account security and session management.
  • BC15 (API Gateway): The unified entry point handling client routing, rate limiting, and context passing.

2. Context Mapping Patterns (The Integration)​

bc-context-mapping
Bounded Context Mapping

To facilitate communication between these isolated microservices without introducing tight coupling, I implemented specific context mapping strategies:

  • Open Host Service (OHS) & Published Language (PL): Leveraged gRPC for synchronous, standardized API communication. Upstream services provide a well-documented protocol (PL) for downstream consumers (e.g., API Gateway fetching session data from Auth).
  • Customer/Supplier (C/S) via Event-Driven Architecture: Utilized NATS for asynchronous event streaming. This ensures downstream services (like BC1 Dashboard) react to upstream changes (like BC11 Market Monitoring) without direct runtime dependency.
  • Anti-Corruption Layer (ACL): Implemented translation layers to protect the core domain models (BC3) from the volatile schemas and unstructured formats of external SEC financial data providers.
  • Conformist (CF): To avoid the over-engineering overhead of building ACLs everywhere, tightly coupled internal domains strategically employ the Conformist pattern. For instance, less critical downstream services strictly conform to the stable upstream domain model (e.g., Watchlist consuming BC3 Company Data), accelerating delivery speed when the upstream model aligns perfectly with downstream needs.
⚙️ DevOps & Deployment Strategy

To manage the complexity of developing and deploying multiple Bounded Contexts, I tailored the infrastructure for different environments:

  • Local Development: Utilized a monorepo setup managed by PM2. This provided a lightweight, highly efficient developer experience for multi-service debugging without the overhead of running local containers.
  • Production Environment: Transitioned the microservices into a Kubernetes (K8s) cluster. K8s is optimally suited for this DDD structure, leveraging its native service discovery, auto-scaling, and self-healing capabilities to manage the distinct resource profiles of each BC.

🌟 Present-Day Retrospective​

The "Microservice Premium" vs. Modular Monoliths:

Did I over-engineer by defining 6 distinct microservices for a self-initiated project? Yes and No.

  • The Gain: It perfectly demonstrated the theoretical purity of DDD. The boundaries are pristine, the deployment scopes are micro-targeted, and testing is highly isolated.
  • The Compromise: Operating a distributed system carries an "infrastructure tax." Managing K8s deployments, CI/CD pipelines, and cross-service tracing for 6 services requires significant DevOps overhead.
  • Future Iteration: If I were to lead this in a fast-paced startup environment optimizing for time-to-market, I would advocate for a "Modular Monolith" approach first. I would keep the 6 logical Bounded Contexts strictly separated at the package/module level within a single deployment unit. I would only extract them into physical microservices (via gRPC/NATS) when specific contexts (e.g., BC11 Market Monitoring) explicitly hit performance or scaling bottlenecks.