Merge branch 'main' into refactor/FluentBuilder

Author: aminsharifi

Directory.Packages.props

@@ -9,7 +9,7 @@
     <PackageVersion Include="Ardalis.SmartEnum" Version="8.1.0" />
     <PackageVersion Include="Ardalis.Specification" Version="8.0.0" />
     <PackageVersion Include="Ardalis.Specification.EntityFrameworkCore" Version="8.0.0" />
-    <PackageVersion Include="Azure.Identity" Version="1.12.1" />
+    <PackageVersion Include="Azure.Identity" Version="1.13.0" />
     <PackageVersion Include="coverlet.collector" Version="6.0.2" />
     <PackageVersion Include="FastEndpoints" Version="5.30.0" />
     <PackageVersion Include="FastEndpoints.ApiExplorer" Version="2.2.0" />

docs/architecture-decisions/README.md

@@ -0,0 +1,52 @@
+# 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
+1. **Be Specific**: Each ADR should address a single architectural decision. Avoid conflating multiple decisions into one record.
+2. **Document Context**: Clearly explain the project’s context and relevant considerations that influenced the decision. Include team dynamics and priorities.
+3. **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.
+
+## Versioning ADRs
+- **Track Changes**: Each time an ADR is updated or a new version is created, increment the version number (e.g., `v1.0`, `v1.1`, etc.) to reflect changes clearly.
+- **Document Changes**: Include a "Changelog" section in the ADR to summarize what has changed in each version. This can include updates to the rationale, context, or decision consequences.
+- **Maintain Clarity**: Ensure the latest version is easily accessible while keeping older versions for reference. You might consider using a version control system (e.g., Git) to manage this effectively.
+
+## How to Start Using ADRs
+1. **Identify Decisions**: Collaborate with your team to identify significant architecture decisions that need documentation.
+2. **Select a Tool**: Choose a tool for documenting ADRs (e.g., markdown files in a Git repository, Google Docs, project management tools).
+3. **Create ADRs**: For each decision, create an ADR file in the `adr` directory, following naming conventions (e.g., `choose-database.md`).
+
+## File Name Conventions
+- Use a present tense imperative verb phrase.
+- Separate words with lowercase letters and dashes.
+- Use `.md` extension for markdown formatting.
+
+## Templates
+Refer to the following templates for structuring your ADRs:
+- [Decision record template by Michael Nygard](https://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions)
+- [Decision record template by Jeff Tyree and Art Akerman](https://github.com/adr/adr)
+- [MADR project templates](https://adr.github.io/madr/)
+
+## Teamwork Advice for ADRs
+- Foster a culture of collaborative decision-making and ensure ADRs are seen as valuable tools rather than bureaucratic requirements.
+- Consider using the term "decisions" instead of "ADRs" to encourage engagement.
+- Maintain living documents by updating existing ADRs with new information rather than rewriting them.
+
+## For More Information
+- [Architectural Decision Wikipedia](https://en.wikipedia.org/wiki/Architectural_decision)
+- [Markdown Architectural Decision Records](https://adr.github.io/)
+- [Tools for working with ADRs](https://github.com/adr/adr)
+
+By following these guidelines, your team can effectively leverage ADRs to enhance architectural decision-making and project transparency while keeping a clear version history of all architectural decisions.

docs/architecture-decisions/adr-001-dotnet-di-adoption.md

@@ -0,0 +1,25 @@
+# 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:
+- Improved support for configuration through extension methods.
+- A simpler learning curve for new contributors familiar with .NET conventions.
+
+## Decision
+Based on community feedback and a review of our project's requirements, we have decided to remove Autofac from this template and transition to using .NET's built-in dependency injection infrastructure. This decision aligns with the goal of simplifying the codebase and reducing external dependencies.
+
+## Consequences
+- **Simplified Codebase**: Removing Autofac results in a cleaner, more maintainable codebase that adheres to .NET standards.
+- **Reduced Complexity**: The transition eliminates the need for additional files and configurations specific to Autofac, making the project easier to understand for new contributors.
+- **Standardization**: Adopting .NET's built-in DI promotes consistency with other .NET projects, making it easier for developers familiar with the framework to contribute effectively.
+
+## References
+- [Issue #649: Why is this repo using Autofac instead of .NET's own DI infrastructure?](https://github.com/your-repo/issues/649) - Discussion that led to this decision.
+- [Getting Started with Architecture Decision Records](https://ardalis.com/getting-started-with-architecture-decision-records/) - Resource on ADR best practices.

sample/src/NimblePros.SampleToDo.Infrastructure/Data/AppDbContext.cs

@@ -1,8 +1,5 @@
-using System.Reflection;
-using Ardalis.SharedKernel;
-using NimblePros.SampleToDo.Core.ContributorAggregate;
+using NimblePros.SampleToDo.Core.ContributorAggregate;
 using NimblePros.SampleToDo.Core.ProjectAggregate;
-using Microsoft.EntityFrameworkCore;
 
 namespace NimblePros.SampleToDo.Infrastructure.Data;
 

sample/src/NimblePros.SampleToDo.Infrastructure/Data/Config/ContributorConfiguration.cs

@@ -1,6 +1,4 @@
 using NimblePros.SampleToDo.Core.ContributorAggregate;
-using Microsoft.EntityFrameworkCore;
-using Microsoft.EntityFrameworkCore.Metadata.Builders;
 
 namespace NimblePros.SampleToDo.Infrastructure.Data.Config;
 

sample/src/NimblePros.SampleToDo.Infrastructure/Data/Config/ProjectConfiguration.cs

@@ -1,6 +1,4 @@
 using NimblePros.SampleToDo.Core.ProjectAggregate;
-using Microsoft.EntityFrameworkCore;
-using Microsoft.EntityFrameworkCore.Metadata.Builders;
 
 namespace NimblePros.SampleToDo.Infrastructure.Data.Config;
 

sample/src/NimblePros.SampleToDo.Infrastructure/Data/Config/ToDoConfiguration.cs

@@ -1,6 +1,4 @@
 using NimblePros.SampleToDo.Core.ProjectAggregate;
-using Microsoft.EntityFrameworkCore;
-using Microsoft.EntityFrameworkCore.Metadata.Builders;
 
 namespace NimblePros.SampleToDo.Infrastructure.Data.Config;
 

sample/src/NimblePros.SampleToDo.Infrastructure/Data/EfRepository.cs

@@ -1,7 +1,4 @@
-using Ardalis.Specification.EntityFrameworkCore;
-using Ardalis.SharedKernel;
-
-namespace NimblePros.SampleToDo.Infrastructure.Data;
+namespace NimblePros.SampleToDo.Infrastructure.Data;
 
 // inherit from Ardalis.Specification type
 public class EfRepository<T> : RepositoryBase<T>, IReadRepository<T>, IRepository<T> where T : class, IAggregateRoot

sample/src/NimblePros.SampleToDo.Infrastructure/Data/Queries/ListContributorsQueryService.cs

@@ -1,5 +1,4 @@
 using NimblePros.SampleToDo.UseCases.Contributors;
-using Microsoft.EntityFrameworkCore;
 using NimblePros.SampleToDo.UseCases.Contributors.Queries.List;
 
 namespace NimblePros.SampleToDo.Infrastructure.Data.Queries;

sample/src/NimblePros.SampleToDo.Infrastructure/Data/Queries/ListIncompleteItemsQueryService.cs

@@ -1,6 +1,4 @@
-using Microsoft.Data.SqlClient;
-using Microsoft.EntityFrameworkCore;
-using NimblePros.SampleToDo.UseCases.Projects;
+using NimblePros.SampleToDo.UseCases.Projects;
 using NimblePros.SampleToDo.UseCases.Projects.ListIncompleteItems;
 
 namespace NimblePros.SampleToDo.Infrastructure.Data.Queries;