Onion Architecture - what are the layers and where to place the services?
I am learning and working out a sample project applying onion architecture and domain driven design.
As per my understanding I have drafted a small presentation and attached as an image in this post.
I need clarifications on layers of onion architecture and its implementation. Could you explain based on my presentation?
Core Project:
Domain Layer - entities, value objects, aggregate root, domain exception objects.
Domain Service Layer - business logic contracts.
Infrastructure Service Layer - persistence contracts, repository contracts, email and sms contracts, domain events and integration events contracts.
Application Service Layer - orchestration of infrastructure and domain service interfaces for uses cases.
Indentity Project:
Web Api Layer - controllers, configuration, composition root etc.
Infrastructure Layer - persistence implementation, repository implementation, email and sms implementation, message queuing etc.
Where would I implement contracts of the domain service layer from core project?
The Onion architecture is cut into these layers :
- The core contains the business rules (in DDD, the Domain Model).
- Around the core there is the Application layer.
- Around the Application layer there is Port (IHM, REST...) and Adapter layer (Persistence, Messaging...).
In your exemple, you have two projects, each project is an onion with all layers.
In addition, don't forget to design/cut your Subdomains with the business expert views. Technical considerations are not a good way for this.
- Using domain driven design entities in an ASP.Net application
- Domain Driven Design Auto Incremented Entity Key
- How to handle paging of sub entities with the repository pattern?
- Is Martin Fowler's POEAA implementation of Unit of Work an anti-pattern?
- Struggle with names in DDD ; how to name my services and entities in external layers?
- If View Model property has value with certain length, replace it with query from database.Do it in Controller, Validation Attribute or somewhere else?
- Is Specification Pattern Pointless?
- DDD Read-Only Repositories returning "value objects"
- DDD driven solution structure
- Using Clean Architecture, am I allowed to Switch Context in Domain Layer ( Use Case )/Or Allowed to use Coroutine Specfic Libraries
- Unsigned number instead of checking invariant in DDD
- Layered architecture, Request and Response DTO, or View Models
- DDD why create interface on domain service?
- Handling Multiple Actors in a Use Case in Clean Architecture and DDD
- Should services always return DTOs, or can they also return domain models?
- DDD Entities making use of Services
- Send, Publish and Request/Response in MassTransit
- CQRS and Domain Driven Design: Anemic data model for Query side
- How to design API endpoint from a DDD perspective
- Dealing with a Factory that uses both a Strategy and Repository
- Class field is not being set
- ddd - Where should synchronization with remote API go?
- DDD: Can immutable objects also be entities?
- Who acts as a conformist in the Customer/Supplier relationship in DDD?
- What is the difference between DAO and Repository patterns?
- Share model between client and server
- EF codefirst : Should I initialize navigation properties?
- How to make a migration to an existing Postgresql database?
- How to choose the proper bounds for an Aggregate in DDD?
- Multiple Hexagonal architecture with sprint boot