Onion architecture applied to an .NET application

Question

I am trying to figure out how to translate the onion architecture into an ASP.NET Core WebAPI solution, this is what I ended up with:

Let's say I have an application that takes a file path / uri into input whether via a Console application or a WebAPI application, read each line and if some business rules are met change the line to a given business specific format and if not return an error as the new line. The application in both Console and WebAPI must be able to return the output (modified lines with new formats as well as the errors which both match a given class (ValueObject?) to Json and Xml.

• Application.Console: a simple CLI that can consume a
• Application.Console.Tests: testing the CLI
• Application.WebApi: exposing the
• Application.WebApi.Tests:
• Domain
• Domain.Tests

What I am struggling and not sure with:

• I would have expected to have an Infrastructure + Infrastructure.Tests but since I don't really have the necessity to use a Database / EF Core atm, I think it's useless, unless I put the configuration of the Swagger / Swashbuckle + Logging configuration into that Infrastructure layer, but I am not sure this is where it belongs.

• I don't really know where to put the file IO reading part into the Infrastructure layer or into another Application.Core, obviously this layer would rely on the domain one and be consumed by both applications.

• For some reasons I think that if both applications need the same output formats, then it's better than the formatting part is implemented in something common instead of performing the same sort of action in both Application.Console and Application.WebApi (even though they would be performed ""differently"" on the surface:

  • The Console project will consume directly Newtonsoft JSON or the XmlSerializer (or another XML serialization library).
  • The WebApi will leverage the builtin formatters: https://docs.microsoft.com/en-us/aspnet/core/web-api/advanced/formatting?view=aspnetcore-2.1#configuring-formatters

• Finally I see in some other projects that the controllers which are typically in the WebApi part are sometimes moved to a dedicated project. I am not really sure whether it makes much sense when there is 1 Controller + 1 Action in the whole solution. So that the Program.cs and Startup.cs will be in an Host project. It might be a bit overkilled except if I want to have my tests to be obviously attached to that project (MyProjectName / MyProjectName.Tests) and integration tests (using Tester: https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-2.1) attached to the host (not sure it makes that much sense though)

Answer 1

Although in this response I do not intend to dive into the ".NET architectural specifics" of your particular case, I would like to introduce the notion that perhaps your present design decisions might be "coupling" these two very-different use cases too much:

• Console Application

• WebAPI Application

Consider, then, dividing the system into three parts:

1. A "console application" -targeted wrapper, or skin.
2. A "WebAPI application" -targeted wrapper, or skin.
3. Application-agnostic core functionality that does not care either way.

Each "wrapper" is responsible for encoding the inputs which they receive into a common format and for issuing appropriate method-calls to the core. Then, they are also responsible for decoding the core's outputs into a format that is appropriate for their specific clientele.

Meanwhile, "the core functionality" is, as I said, "agnostic." It always knows that it will be communicated-with by a wrapper, and that it will communicate-via the same wrapper, but it doesn't have to care which wrapper it is.

I think that this "separation of concerns" will quickly help you to sort out your design issues, and – without in any way whatsoever appearing to "talk down(!) to you" – "I hope this helps."