Domain-Driven Design (DDD) Practice in a Reward Service: Architecture, Strategic and Tactical Design

Domain‑Driven Design (DDD) was defined by Eric Evans about 17 years ago and has long been a methodology for traditional industry software engineering. In recent years it has become popular in the Internet industry because business complexity has increased and micro‑service architectures need a way to split services.

The article first presents the business value that DDD brought to a reward (打赏) system: new‑feature integration cost reduced by 20%, middleware replacement cost reduced by 20%, project onboarding cost reduced by 30%, unit‑test development cost decreased exponentially, and overall launch risk and cost were lowered.

A concrete reward‑interface example is shown, highlighting code smells such as loss of parameter names after compilation, mixing of business logic with pre‑validation logic, and a monolithic method that hampers readability and testing.

The root cause is the lack of clear domain boundaries. The article introduces core DDD concepts—domain, sub‑domain, bounded context—and explains how the reward system is split into sub‑domains such as core reward, notification, reward strategy, ranking, activity management, and user services.

Strategic design leads to a layered architecture that follows the Hexagonal (or Onion/Clean) architecture. The domain layer contains the business model, the application layer orchestrates use cases, the infrastructure layer implements interfaces, and the outer adapters (e.g., HTTP, messaging) connect to external systems. Dependency Inversion is applied so that high‑level modules depend on abstractions rather than concrete implementations.

Tactical design covers the DDD building blocks:

Entity – objects with identity and behavior.

Value Object – immutable objects without identity.

Domain Service – stateless operations that do not fit in entities or value objects.

Domain Event – events that capture important domain occurrences.

Aggregate – a cluster of related objects with a root entity.

Factory – encapsulates complex object creation.

The article also discusses the advantages of applying DDD with Hexagonal architecture: independence from frameworks, UI, data sources, and external dependencies.

Key practical issues are addressed:

Transaction – keep a transaction within a single aggregate; use eventual consistency for larger scopes.

Query – adopt CQRS to separate read models from the domain model.

Framework independence – isolate Spring beans via parameter injection.

Cost – evaluate learning, migration, and compatibility costs before adopting DDD. Finally, the article provides a module breakdown (admin‑api, api, application, domain, infrastructure, query, task, worker, common) and shows how repositories and RPC services are placed in the domain and infrastructure layers. In conclusion, DDD is not a brand‑new architecture but a methodology to manage software complexity, leading to high maintainability, scalability, testability, and clear code structure after refactoring.