| Name | Message | Date |
|---|---|---|
| 📁 src | 1 day ago | |
| 📄 .gitignore | 3 days ago | |
| 📄 IMPROVEMENTS.md | 1 day ago | |
| 📄 README.md | 4 days ago | |
| 📄 Walley.Checkout.sln | 4 days ago |
Improvements
UnitPrice of OrderLine shouldn't be part of the API call, it should be looked up in DB based on ProductName (or even better an id).
Separate domain models from API. Right now we need to consider the shape of the API when updating the "domain" models.
Document all response types and status codes in the OpenAPI specification.
CancellationTokens are never a bad idea.
Use an injected TimeProvider. This will help reduce flakey unit tests as the tests no longer rely on actual wall time.
Non of the OrderServiceTests are very interesting, because there's no interesting logic in the OrderService.
Consider moving the test project to /test. If not I'd suggest to simply remove /src and have all projects in the root directory.
Task 4: Considerations
Using the built-in ProblemDetails instead of a custom exception format for a unified response format on all kinds of errors.
My philosophy is that any exception thrown should be truly exceptional, and therefore all exceptions should be returned as 500 errors. In case of an expected error happening in the service (or lower) it should be visible in the return type, and the controller should map it to an appropriate response. Right now the only expected "error" is not finding an order, so returning a nullable order is fine, but if other expected errors (such as unauthorized access maybe) is added to the service logic then the return type has to change.