Which layer to handle response code decision in Clean Architecture - asp.net-core

Question

Currently implementing Clean Architure using MediatR with
IRequestHandler<IRequest<ResponseMessage>, ResponseMessage>
IRequest<ResponseMessage>
The implementation now separates between business logic layer, infrastructure and controller and they rely on dependency injection and decoupled.
Currently the implementation is in Asp.Net Core and this framework supports response code generation done in controller as example below.
[HttpGet]
[ProducesResponseType(200)]
[ProducesResponseType(404)]
public async Task<IActionResult> GetObject([FromQuery] int Id)
{
...
return Ok(some_result_to_show); // This generates code 200
}
I wonder where in Clean Architecture layer should translate business rule decisions made into correct response codes and what would be good practice or set methodology doing this adaption.
Seems quick implementation would be still doing it in controller however wonder if this decision belongs to business rules or application business rules and should be handled in different layer before translating into response code in presentation layer.
If then Asp.Net core or MediatR (or any other library) has in-built framework or features to support such design.

Answer 1

One way I found is as below
In the business layer,
RequestMessageValidator : AbstractValidator<RequestMessage>
{
RuleFor(r => r).{ConditionSyntax}().WithErrorCode(ResponseCodeString);
}
Then in the controller,
return StatusCode(
Convert.ToInt32(ValidationResult.Errors[0].ErrorCode),
ValidationResult.Errors[0].ErrorMessage);

Answer 2

It is definitely the application / presentation layer which is MVC or your controllers. I would suggest you to throw specific exceptions that serve only one purpose.
For instance when you query data you will have a request-handler that looks for the data that should be found using a given id (a guid, or whatever). Now that identifier is valid but it is none existence on your database. You don't want to access the httpcontext (even though you could) in your handler because than your businesslogic would be coupled to asp.net. Throw an exception that tells you, that a resource was not found to produce a 404 error response (let's call it ResourceNotFoundException i.e.). For that exception you can then use an exception-filter instead of data-annotation above your controller-endpoints. You can have many exception-filter. Each serves its own purpose.
If you do it like that, your businesslogic will be decoupled from any application / presentation layer and can easily be reused where ever you want.
If you want to see an example of how an exception-filter works, I've created a simple solution for that a while ago. You can find it here.
Not directly related to your question but instead of returning an IActionResult, you could also return a data-transfer-object when you want to send data to the client. It will also produce a Http.OK statuscode.