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 & Hexagonal Architecture

Domain-Driven Design (DDD) and Hexagonal Architecture are highly complementary because both focus on separating business logic from external concerns.

• In Hexagonal Architecture, the Domain Layer aligns perfectly with DDD's core domain. It contains entities, value objects, aggregates, and domain services, ensuring business rules remain untouched by technical dependencies.
• The Application Layer in Hexagonal Architecture acts as a bridge between the domain and external components, implementing application services that coordinate use cases.
• The Infrastructure Layer houses repositories, APIs, and external systems, using adapters to communicate with the core domain without coupling business logic to technical details.

By combining DDD with Hexagonal Architecture, software remains modular, testable, and adaptable to change. Business logic is isolated in a way that allows teams to iterate quickly, change technologies without rewriting core logic, and scale efficiently. This makes it a powerful approach for enterprise applications, microservices, and any system that requires long-term maintainability.

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.