In my recent 𝗘𝗺𝗽𝗹𝗼𝘆𝗲𝗲 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗥𝗲𝘃𝗶𝗲𝘄 𝗦𝘆𝘀𝘁𝗲𝗺 project, I implemented the 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 as part of the 𝗖𝗹𝗲𝗮𝗻 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 approach — and it transformed the way I structured my application logic.
🧩 What is a Use Case in Clean Architecture?
A 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲 represents a 𝘀𝗶𝗻𝗴𝗹𝗲 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗼𝗿 𝗶𝗻𝘁𝗲𝗿𝗮𝗰𝘁𝗶𝗼𝗻 from the user's perspective, such as:
-
CreateReview,SubmitReview,UpdateReview,DeleteReview
It fits into the 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗟𝗮𝘆𝗲𝗿, where it:
✅ Orchestrates application rules
✅ Uses domain entities & value objects
✅ Calls interfaces like IReviewRepository
✅ Does 𝗻𝗼𝘁 depend on frameworks, databases, or UI code
🛠️ Example: Using Repository in Use Case
public class CreateReviewUseCase
{
private readonly IReviewRepository _reviewRepository;
public CreateReviewUseCase(IReviewRepository reviewRepository)
{
_reviewRepository = reviewRepository;
}
public async Task ExecuteAsync(CreateReviewDto dto)
{
var review = new EmployeeReview(dto.EmployeeId, ReviewScore.Create(dto.Score), dto.Comments);
await _reviewRepository.AddAsync(review);
}
}
This use case calls the repository but knows nothing about the actual database.
🧠 How We Use It in the Controllers:
In your Controllers or API Endpoints, you can simply call the use case:
public async Task CreateReview(CreateReviewDto model)
{
await _createReviewUseCase.ExecuteAsync(model);
return RedirectToAction("Success");
}
This separation keeps controllers 𝘁𝗵𝗶𝗻 𝗮𝗻𝗱 𝗰𝗹𝗲𝗮𝗻, and ensures 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗹𝗼𝗴𝗶𝗰 𝗹𝗶𝘃𝗲𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗽𝗹𝗮𝗰𝗲.
If you're aiming to build 𝘀𝗰𝗮𝗹𝗮𝗯𝗹𝗲, 𝘁𝗲𝘀𝘁𝗮𝗯𝗹𝗲, 𝗮𝗻𝗱 𝗰𝗹𝗲𝗮𝗻 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀, try applying 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 in the 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗟𝗮𝘆𝗲𝗿 — it makes your business rules easier to manage and evolve.
𝗛𝗮𝘃𝗲 𝘆𝗼𝘂 𝗲𝘃𝗲𝗿 𝘄𝗼𝗻𝗱𝗲𝗿𝗲𝗱 𝗵𝗼𝘄 𝘁𝗼 𝗼𝗿𝗴𝗮𝗻𝗶𝘇𝗲 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗹𝗼𝗴𝗶𝗰 𝗰𝗹𝗲𝗮𝗻𝗹𝘆 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝘁𝗶𝗴𝗵𝘁𝗹𝘆 𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 𝗶𝘁 𝘁𝗼 𝘆𝗼𝘂𝗿 𝗨𝗜 𝗼𝗿 𝗱𝗮𝘁𝗮 𝗮𝗰𝗰𝗲𝘀𝘀 𝗹𝗮𝘆𝗲𝗿?
Top comments (0)