Skip to main content

Attendance Application Layer

Summary

The application layer exposes use-case services rather than mediator handlers.

Audience

Backend developers, QA engineers, and solution architects.

Responsibilities

AttendanceCommands handles save, approval, and rejection. AttendanceQueries builds weekly, pending, approved-period, monthly-summary, and roster results. PunchWorkflow and ReopenRequestWorkflow coordinate multi-aggregate use cases. EmployeeProfileService, PayrollSnapshotService, ShiftPolicyCommands, ShiftPolicyQueries, and compatibility services cover supporting boundaries.

Input DTOs are presentation-neutral request shapes; response DTOs and explicit mapping extensions preserve compatibility. Application services perform request validation, reference lookup, authorization-derived scoping supplied by presentation, domain calculation/mutation, audit/timeline coordination, and one unit-of-work commit. A lightweight Result<T> distinguishes validation, not-found, conflict, forbidden, and success outcomes.

There is no MediatR dependency, handler registry, or separate validator framework. Minimal API delegates resolve scoped services directly through parameters or dependency injection. Domain exceptions cover invariant violations; application results cover expected use-case failures. Outbox mapping occurs during persistence commit, not in application services.

Source References

  • microservices/src/attendance-service/Application/Common/Cqrs.cs
  • microservices/src/attendance-service/Application/Common/Abstractions.cs
  • microservices/src/attendance-service/Application/Dtos.cs
  • microservices/src/attendance-service/Application/Mappings.cs
  • microservices/src/attendance-service/Application/Services/AttendanceCommands.cs
  • microservices/src/attendance-service/Application/Services/AttendanceQueries.cs

See Also

Keywords

  • Attendance Service
  • Attendance Application Layer

Revision Information

  • Status: Draft
  • Last reviewed: 2026-07-15
  • Review cycle: Quarterly