ADR 001: Replace Autofac with .NET DI

Mon, 01 Jan 0001 00:00:00 +0000

ADR 001: Replace Autofac with .NET Core Dependency Injection#

Status#

Accepted

Context#

Initially, this repository employed Autofac for dependency injection. At the time of adoption, Autofac was preferred due to its robust feature set, including:

Support for advanced scenarios such as decorators and modules, which could be placed close to their corresponding implementations.
A well-established history of stability and maturity, having been used in various projects before .NET Core’s built-in DI was fully featured.

As the .NET ecosystem evolved, the built-in DI container began to meet the needs of our project without introducing the added complexity associated with Autofac. The .NET DI framework has matured significantly, offering sufficient functionality for typical use cases, including:

Mon, 01 Jan 0001 00:00:00 +0000

Architecture Decision Records (ADR)#

What is an Architecture Decision Record (ADR)?#

An Architecture Decision Record (ADR) documents significant architecture decisions made throughout a project, capturing the context, rationale, and consequences of each decision. This promotes transparency and provides a historical reference for future design considerations.

Purpose of ADRs#

Knowledge Management: Consolidates architectural knowledge and decisions.
Collaboration: Enhances team communication by documenting discussions and outcomes.
Clarity: Provides clear reasoning behind design choices, making it easier for new team members to understand past decisions.

Best Practices for Writing ADRs#

Be Specific: Each ADR should address a single architectural decision. Avoid conflating multiple decisions into one record.
Document Context: Clearly explain the project’s context and relevant considerations that influenced the decision. Include team dynamics and priorities.
Rationale and Consequences: Describe the reasons for the decision, including pros and cons, and outline the implications of the decision for the project and

future architecture. 4. Immutable Records: Once an ADR is created, avoid altering it. Instead, create a new ADR to reflect any changes or updates. 5. Timestamp Entries: Include timestamps to track when each decision was made, especially for aspects that may evolve over time (e.g., costs, schedules). 6. Use Templates: Utilize established templates for consistency and completeness in documenting ADRs.

Architecture Decisions on Ardalis Clean Architecture