Creating BuscaVoosTeste.sln: Project Setup & Initial Files
Embarking on a new software project can be an exciting endeavor, and setting up the initial structure correctly is crucial for long-term success. This article delves into the step-by-step process of creating the BuscaVoosTeste.sln solution, establishing the foundational architecture projects, and configuring the initial repository files. We'll explore how to implement a clean architecture pattern using .NET 10 and C# 14, ensuring a robust and maintainable codebase. Let's dive into the essential elements needed to kickstart your project effectively.
Understanding the Initial Setup
The primary goal here is to lay the groundwork for our project. This means constructing the initial solution structure and projects in .NET, alongside setting up the basic repository files. It's important to emphasize that we will not be implementing domain classes, use cases, providers, DTOs, or endpoints at this stage. Our focus remains solely on creating a skeletal structure ready for future development.
This project will adhere to the principles of Clean Architecture, leveraging the capabilities of .NET 10 and C# 14. The repository will include an instruction file named instructions/instrucoes-busca-voos-duffel.md, providing overall guidance. For now, our task is limited to the creation of the solution, empty projects, and initial repository files.
Step-by-Step Guide to Creating the Solution and Projects
1. Creating the BuscaVoosTeste.sln Solution
The first step is to create the solution file itself. This file serves as a container for all the projects that make up our application. To create the solution, use the .NET CLI or your preferred IDE, ensuring it is named BuscaVoosTeste.sln and placed at the root of the repository.
To accomplish this via the .NET CLI, navigate to your desired root directory in the terminal and execute the following command:
$ dotnet new sln -n BuscaVoosTeste
This command initializes a new solution named BuscaVoosTeste.sln. This solution will serve as the backbone for all of our projects and their interconnections. The solution file is essentially a roadmap, guiding the build process and helping developers navigate the codebase. Ensuring its proper creation is paramount, as it influences the project's organization and compilation workflow from the outset. In the next steps, we will add the necessary projects to this solution, structuring our application according to the principles of Clean Architecture.
2. Creating the Base Projects
Inside the src/ folder, we will create five empty projects, each targeting the net10.0 framework and with nullable enabled. These projects form the layers of our Clean Architecture:
BuscaVoosTeste.DomainBuscaVoosTeste.ApplicationBuscaVoosTeste.InfrastructureBuscaVoosTeste.ApiBuscaVoosTeste.McpServer
Let's detail the creation of each project:
a. BuscaVoosTeste.Domain
This project will contain our core business logic and domain entities. It should not depend on any other projects within the solution. To create this project, navigate to the src/ directory and run:
$ dotnet new classlib -n BuscaVoosTeste.Domain -f net10.0
Next, open the .csproj file and add <Nullable>enable</Nullable> within the <PropertyGroup> tag to enable nullable reference types. The Domain layer is the heart of our application, encapsulating the core business rules and entities. It's vital that this layer remains independent of external dependencies, ensuring the business logic is reusable and testable in isolation. By not referencing other projects, we ensure that the domain logic remains pure and focused. This independence allows the Domain layer to evolve without being affected by changes in other parts of the application, adhering to the core principles of Clean Architecture and maintaining a stable foundation for the entire system. The command line interface provided by .NET makes this process straightforward, and adding the nullable feature at this stage helps in preventing null reference exceptions, thereby enhancing the robustness of our codebase.
b. BuscaVoosTeste.Application
This project houses the application logic and use cases. It depends on the BuscaVoosTeste.Domain project but should not depend on Infrastructure. Create the project using:
$ dotnet new classlib -n BuscaVoosTeste.Application -f net10.0
Again, enable nullable reference types in the .csproj file. Then, add a project reference to BuscaVoosTeste.Domain. The Application layer acts as the orchestrator of our business logic, implementing use cases and coordinating actions between the Domain layer and the outside world. By referencing only the Domain layer, we maintain a clear separation of concerns, ensuring that application-specific logic does not bleed into our core business rules. This approach also facilitates testability, as we can mock Domain layer components to test application use cases in isolation. The inclusion of nullable reference types, which we enable by adding the corresponding tag in the .csproj file, is a proactive step towards preventing null-related exceptions, making our application more resilient and dependable. The consistency in project creation, as demonstrated through the CLI commands, reinforces good development practices and streamlines the setup process.
c. BuscaVoosTeste.Infrastructure
This project implements the interfaces defined in the Application layer and interacts with external systems. It depends on both Domain and Application. Create the project using:
$ dotnet new classlib -n BuscaVoosTeste.Infrastructure -f net10.0
Enable nullable and add references to BuscaVoosTeste.Domain and BuscaVoosTeste.Application. The Infrastructure layer is where we handle external interactions such as database access, network communication, and file system operations. This layer is critical for integrating our application with the outside world, but it is also where dependencies are most likely to introduce complexity. By adhering to the principles of Clean Architecture, we ensure that these infrastructural concerns are kept separate from our core business logic. The Infrastructure layer implements the interfaces defined in the Application layer, which allows us to swap out implementations without affecting the core application. Referencing both the Domain and Application layers allows the Infrastructure layer to utilize domain entities and implement application contracts, providing a cohesive integration point. Enabling nullable reference types continues our commitment to writing safer and more reliable code, minimizing the risk of null reference exceptions.
d. BuscaVoosTeste.Api
This project is our ASP.NET Core Web API, responsible for exposing our application to the outside world. It depends on Application and Infrastructure. Create it using:
$ dotnet new webapi -n BuscaVoosTeste.Api -f net10.0
Enable nullable and add references to BuscaVoosTeste.Application and BuscaVoosTeste.Infrastructure. The API layer acts as the entry point for external requests, translating them into application use cases and returning responses. By adhering to Clean Architecture, our API remains thin and focused, delegating business logic to the Application layer and infrastructure concerns to the Infrastructure layer. This separation of concerns makes our API more maintainable, scalable, and testable. Referencing the Application layer allows the API to invoke use cases, while referencing the Infrastructure layer provides the necessary implementations for these use cases. Enabling nullable reference types in the .csproj file is a consistent practice that improves the safety and reliability of our code by making nullability explicit.
e. BuscaVoosTeste.McpServer
This is a Console Application (or a worker service) that will act as an MCP (Message Control Protocol) server. It depends on Application and optionally Infrastructure. Create it using:
$ dotnet new console -n BuscaVoosTeste.McpServer -f net10.0
Enable nullable and add a reference to BuscaVoosTeste.Application. You might optionally reference BuscaVoosTeste.Infrastructure if needed for your MCP implementation. The MCP Server project is designed to handle background tasks and message processing, allowing our main API to focus on serving user requests. By structuring this as a separate console application or worker service, we can scale and manage background processes independently. This architecture decision improves the overall resilience and performance of our system. Referencing the Application layer allows the MCP Server to trigger application use cases based on incoming messages, while the optional reference to the Infrastructure layer can facilitate interaction with external systems. Enabling nullable reference types ensures that our background processing code is as robust and reliable as our API layer.
3. Setting up Initial Repository Files
Now, let's create the initial files for our repository:
a. README.md
A README.md file at the root provides an overview of the project. It should include:
- Name of the solution:
BuscaVoosTeste.sln - Brief description of the project
- Architecture overview
- Folder structure overview
- Technologies used
Here’s an example of what the README.md might contain:
# BuscaVoosTeste.sln
A POC in .NET 10 + C# 14 for flight search using the Duffel API.
## Overview
This project aims to demonstrate flight search capabilities using the Duffel API within a .NET environment. It follows the Clean Architecture principles to ensure maintainability and scalability.
## Architecture
The project is structured using Clean Architecture, which includes the following layers:
* **Domain**: Core business logic and entities.
* **Application**: Use cases and application-specific logic.
* **Infrastructure**: External system interactions and implementations.
* **Api**: ASP.NET Core Web API for external access.
* **McpServer**: Console application for background tasks.
## Folder Structure
```text
/BuscaVoosTeste.sln
├── README.md
├── .gitignore
└── src/
├── BuscaVoosTeste.Domain/
├── BuscaVoosTeste.Application/
├── BuscaVoosTeste.Infrastructure/
├── BuscaVoosTeste.Api/
└── BuscaVoosTeste.McpServer/
Technologies Used
- .NET 10
- C# 14
- ASP.NET Core
- Clean Architecture
The **README.md** file is often the first point of contact for anyone encountering your project, whether they are potential contributors, users, or stakeholders. A well-crafted README.md serves as a comprehensive introduction, providing essential information about the project's purpose, architecture, and usage. In our case, the README.md begins with the project name, BuscaVoosTeste.sln, immediately establishing the context. The brief description outlines the project's goals, emphasizing its use of the Duffel API for flight search and its implementation in .NET 10 and C# 14. The overview section elaborates on the project's adherence to Clean Architecture, detailing the roles of the Domain, Application, Infrastructure, Api, and McpServer layers. This high-level architectural summary helps readers quickly grasp the project's structure and design principles. The folder structure section provides a visual representation of the project's organization, which aids in navigation and understanding the layout. Finally, the technologies used section lists the core technologies, giving developers a quick insight into the tech stack. By including all this information, the README.md ensures that newcomers have a solid foundation for understanding and contributing to the project.
#### b. `.gitignore`
A `.gitignore` file prevents unnecessary files from being committed to the repository. A typical .NET `.gitignore` should include:
```text
bin/
obj/
.vs/
.idea/
.vscode/
*.user
*.suo
*.userprefs
*.log
Logs/
The .gitignore file is an essential component in any software development project, especially when using version control systems like Git. Its primary purpose is to specify intentionally untracked files that Git should ignore, thereby preventing them from being committed to the repository. This is crucial for maintaining a clean and efficient repository, as it avoids the inclusion of files that are not necessary for project collaboration or deployment, such as build artifacts, local IDE settings, and temporary files. The example .gitignore content provided includes common patterns for .NET projects. The bin/ and obj/ directories, which contain compiled binaries and intermediate build files, are ignored to prevent the repository from being cluttered with build outputs. IDE-specific directories like .vs/ for Visual Studio, .idea/ for IntelliJ IDEA, and .vscode/ for Visual Studio Code are also included to ensure that local development environment settings are not shared. User-specific files such as *.user, *.suo, and *.userprefs, which often contain personalized settings, are excluded as well. Log files and directories, like *.log and Logs/, are typically ignored to avoid committing potentially sensitive or large log data. By carefully curating the .gitignore file, developers can ensure that only relevant source code and project assets are tracked, leading to a cleaner, more manageable repository.
c. (Optional) .editorconfig
An .editorconfig file helps maintain consistent coding styles across different editors and IDEs. A basic .editorconfig might include:
root = true
[*]
charset = utf-8
end_of_line = crlf
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = true
[*.cs]
indent_style = space
indent_size = 4
The .editorconfig file plays a crucial role in ensuring code consistency across different development environments. In collaborative software projects, developers often use various IDEs and text editors, each with its own default settings. This can lead to inconsistencies in coding styles, such as indentation, line endings, and character encoding, which can make codebases harder to read and maintain. The .editorconfig file addresses this issue by providing a standardized way to define and share coding style guidelines. The example provided starts with root = true, indicating that this .editorconfig file applies to the current directory and all subdirectories. The [] section specifies default settings for all file types, including charset = utf-8 for character encoding, end_of_line = crlf for line endings (common on Windows), and indent_style = space with indent_size = 4 for indentation. The trim_trailing_whitespace = true and insert_final_newline = true settings help maintain clean code by removing unnecessary whitespace. The [.cs] section provides C#-specific settings, reinforcing the use of space indentation with a size of 4. By including an .editorconfig file in the project repository, teams can ensure that code adheres to a consistent style, improving readability, reducing merge conflicts, and promoting overall code quality.
Conclusion
Setting up the initial structure for a new project is a critical step in ensuring its success. By creating the BuscaVoosTeste.sln solution, establishing the base projects following Clean Architecture principles, and configuring the initial repository files, we've laid a strong foundation for future development. This structured approach not only facilitates a more organized workflow but also enhances the maintainability and scalability of the project.
For more insights into Clean Architecture and best practices in .NET development, consider exploring resources like Microsoft's official .NET documentation.
