Domain Driven Design

Domain-Driven Design (DDD) is a software development approach that emphasizes structuring software around the core business domain rather than technical concerns. It is particularly useful for complex applications, where understanding and modeling real-world business processes is critical.

DDD provides a common language—known as the Ubiquitous Language—that developers and domain experts share, ensuring alignment between business requirements and software implementation. Instead of focusing on databases, frameworks, or low-level details, DDD encourages designing software around real-world concepts and business logic.

Key Concepts of DDD

DDD introduces several core principles and patterns to help developers build highly maintainable and scalable applications:

• Bounded Contexts – Large systems are divided into clearly defined contexts, each with its own domain model and business rules. This prevents ambiguity and makes teams more autonomous.
• Entities & Value Objects – Entities are objects with a unique identity that persists over time (e.g., a user or an order). Value Objects are immutable and defined by their attributes (e.g., a money amount or a date range).
• Aggregates – Groups of related entities that are treated as a single unit to enforce consistency (e.g., an order and its associated order items).
• Repositories – Abstractions that provide access to aggregates, ensuring business logic remains independent of database implementation.
• Services – Business logic that does not naturally fit within an entity or aggregate is placed inside domain services.

Domain Driven Design & CQRS

Domain-Driven Design (DDD) and CQRS are highly complementary because both help structure complex systems around business intent and clear responsibilities.

• DDD gives the system its domain model: entities, value objects, aggregates, repositories, and services that reflect the business rather than framework or transport concerns.
• CQRS shapes how those domain concepts are used by separating commands from queries. Commands handle state-changing use cases, while queries focus on reading and returning data efficiently.
• Together, DDD and CQRS help keep controllers thin, application flows explicit, and business rules isolated from read-model concerns, making the codebase easier to evolve over time.

By combining DDD with CQRS, software remains modular, testable, and adaptable to change. The domain layer can focus on enforcing business rules, while the application layer cleanly separates write logic from read logic. This makes the architecture easier to reason about and especially useful for systems expected to grow in complexity over time.

Where is it used in the stack?

The RawStack API isn't strictly bound to DDD principles, but it draws heavily from the core concepts of both Hexagonal Architecture and Domain-Driven Design, ensuring a clean, scalable, and maintainable structure.