DDD (Domain Driven Design)

Application Layer

- ASP.NET Web API - Network access to microservice - API contracts\implementation - Commands and command handlers - Queries(micro or)

Infrastructure Layer

- Data persistence infrastructure(repository implementation) - Use of ORMs or Data Access API - Other infrastructure implementation used from application layer(logging, security, cryptograhy)

Domain Layer

- Domain Entity Models - POCO entity classes - Domain entities with data + behaviour - DDD patterns: Domain entity, aggregate; Aggregate root, value object; Repository contracts; Services contracts

Anemic domain model

Domain model that lack of methods - just getters and setters. Consider as anti-pattern, mostly used for simple microservices with simple CRUD entities.

Value object

Immutable objects without identity. (For example address)

Integrations events

Purpose of integration events i s to propagate committed transactions and updates to additional subsystems.

Entities

Represents domain objects and are primary defined by their identity, continuity, and persistence over time. Entities must implement behavior(related to entity data) in addition to implementing data attributes.

Aggregate Root

Root entity in aggregate. The purpose of an aggregate root is to ensure the consistency of the aggregate. it should be the only entry point for updates to the aggregate through methods or operations in the aggregate root class.

Aggregates

The domain model that contains clusters of different data entities and behaviors that can be treated as a cohesive unit. You usually define an aggregate based on the transactions that you need. A classic example is an order that also contains a list of order items. An order item will usually be an entity.

Domain Events

Use domain events to explicitly implement side effects across multiple aggregates. Domain events is something that happened in a particular domain, and something you want other parts of the same domain to be aware of and potentially react to