LMS Project Structure

Summary

Audience

Developers, QA, architecture, security, and maintainers.

Reference Content

Area	Actual contents	Separation
Api	Endpoint registration, endpoint-local helpers, input/output/report DTOs	Folder/namespace convention
Application	Tenant context, validation exception, Document port/options/adapter	Folder/namespace convention; adapter is colocated
Domain	Entities, value records, enums, evidence/processed types	Single domain file
Infrastructure	DbContext/configuration, outbox mapping/store, evidence helpers, migrations, seed, design factory	Folder/namespace convention
Project root	Bootstrap, project file, runtime settings, container definition	Single web project
Shared Kernel/contracts	Separate referenced projects	Assembly references

No Training Messaging, Compatibility, Backfill, or test project/folder exists. API, Application, Domain, and Infrastructure compile together, so dependency direction is not enforced by project references.

Requires confirmation

Fine-grained authorization, production ownership, operational governance, and future architectural boundaries require confirmation where not implemented.

Source References

• microservices/src/training-service/training-service.csproj
• microservices/src/training-service/Program.cs
• microservices/src/training-service/Api/TrainingEndpoints.cs
• microservices/src/training-service/Domain/TrainingEntities.cs
• microservices/src/training-service/Application/Common.cs
• microservices/src/training-service/Infrastructure/TrainingDbContext.cs

Related Articles

• LMS technical documentation
• LMS business documentation

See Also

• Technical limitations
• Technical source map

Keywords

• LMS technical architecture
• Source-backed implementation

Revision Information

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