Workflow Layer Dependencies
Summary
The service follows a pragmatic layered design: API depends on Application and Infrastructure; Application depends on Domain and selected Infrastructure for queries; Infrastructure implements Domain and Application contracts.
Dependency diagram
Boundary details
Command classes consume repository interfaces and application ports. Repository interfaces live in Domain. Query code uses the DbContext rather than a read-repository abstraction. Infrastructure owns ASP.NET tenant extraction and EF Core mappings.
Consequences
Aggregate mutation remains isolated from persistence mechanics. The query-side DbContext dependency is an intentional shortcut and means Application is not infrastructure-independent.
Limitations
There is no formal mediator pipeline, separate read store, dependency-rule test or module-boundary test.
Requires Confirmation
Whether direct DbContext queries are the target architecture or transitional requires confirmation.
Source References
microservices/src/workflow-service/workflow-service.csprojmicroservices/src/workflow-service/Program.csmicroservices/src/workflow-service/Application/Common/Abstractions.csmicroservices/src/workflow-service/Infrastructure/Persistence.cs
Related Articles
See Also
Keywords
Workflow architecture, approval engine, Workflow Service, technical foundation.
Revision Information
- Status: Draft
- Last reviewed: 2026-07-20
- Next review: 2026-10-20