Am I violating SOLID principles and n-layer, micro service architectures?

Question

In the following example, the AccountService and ProductService are in an ASP.NET MVC app. The AccountWebAPI and ProductWebAPI are externally hosted API micro services.

1) Can I eliminate the ProductService and orchestrate the retrieving of the orders in the CustomerAccountController itself? This is because I consider the Controller as the Application layer/service which is mentioned in the DDD (Domain Driven Design).

2) Am I violating the n-layer architecture because the ProductService calls the AccountService which is the same layer?

3) Since AccountWebAPI and ProductWebAPI are micro services, do they have to be separated as AccountService and ProductService in the client application (MVC App) also to keep the Separation Of Responsibility? So the ProductService needs to be renamed as ProductAppService and ProductService should interact with ProductWebAPI only like AccountService talks to AccountWebAPI.

public class CustomerAccountController : Controller 
{ 
    IProductService _productService;

    public CustomerAccountController(IProductService productService)
    {
        _productService = productService;
    }

    public IActionResult Index()
    {
        return View();
    }

    public IActionResult Account(int customerId)
    {
        var orders = _productService.GetOrders(customerId);

        return View(orders);
    }
}

public class ProductService 
{ 
    IAccountService _accountService; 
    IProductWebAPI _productWebAPI;

    ProductService(IAccountService accountService, IProductWebAPI productWebAPI)
    {
        _accountService = accountService;
        _productWebAPI = productWebAPI;
    }

    IList<Order> GetOrders(int customerId)
    {
        // Find the International Customer Number for CustomerId
        object customer = _accountService.GetInternationCustomerInfo(customerId);

        // Convert the string type to int
        var modifiedCustomerNumber = Convert.ToInt32(customer.Id);

        // Get the orders
        return _productWebAPI.GetOrders(modifiedCustomerNumber);
    }
}

public class AccountService 
{ 
    IAccountWebService _accountWebAPI;

    CustomerService(IAccountWebService accountWebAPI)
    {
        _accountWebAPI = accountWebAPI;
    }

   object GetInternationCustomerInfo(int customerId) 
   { 
        return accountWebAPI.GetCustomer(customerId) 
   } 
}

UPDATE: I realized that OrderService would be the appropriate service name for orders and not ProductService.

The LAYERS:

VIEW -- CONTROLLER -- SERVICE -- WebAPIs -- DOMAIN -- REPOSITORY

OrderView -- CustomerAccountController -- ProductService (calls AccountService in the same layer) -- ProductWebAPI -- ProductDomain -- ProductRepository

Answer 1

The names AccountService and ProductService imply that you are violating the Single Responsibility Principle, Open Closed Principle and Interface Segregation Principle. Together, those three principles are 60% of the SOLID principles.

The reasoning for this is explained in this article, but in short:

The Single Responsibility Principle is violated, because the methods in each class are not highly cohesive. The only thing that relates those methods is the fact that they belong to the same concept or entity.

The design violates the Open/Closed Principle, because almost every time [a method] is added to the system, an existing interface and its implementations need to be changed. Every interface has at least two implementations: one real implementation and one test implementation.

The Interface Segregation Principle is violated, because the interfaces [such as IProductService] are wide (have many methods) and consumers of those interfaces are forced to depend on methods that they don’t use.

The solution is to give each use case its own class. This design is explained in detail here and here.

I would even say that having Web API controllers with the same structure leads to the same kind of SOLID violation. In fact, if you apply the design given by the articles, you can completely remove all your Web API controllers, and replace them with a single piece of infrastructure logic that will be able to pass messages around. Such design is described here (the article mainly talks about WCF, but its applicable to Web API as well and a working example of Web API can be seen in the example project that the article links to).

Answer 2

1) Can I eliminate the ProductService and orchestrate the retrieving of the orders in the CustomerAccountController itself?

You could do that, but that means you would mix up delivery logic with applicative logic. It's not the worst SRP violation but that would remove the option of adding a second delivery mechanism (something else than Web API) for the same use case. It can be a valid tradeoff in some circumstances though.

2) Am I violating the n-layer architecture because the ProductService calls the AccountService which is the same layer?

Absolutely not. An architecture is a set of constraining technical decisions that were made. The only way you could violate an architecture would be to set up a second, parallel architecture that somehow breaks principles from the original one. Here, you wouldn't even violate the n-layer approach since nothing in it says that you shouldn't call someone in the same layer.

3) Since AccountWebAPI and ProductWebAPI are micro services, do they have to be separated as AccountService and ProductService in the client application (MVC App) also to keep the Separation Of Responsibility? So the ProductService needs to be renamed as ProductAppService and ProductService should interact with ProductWebAPI only like AccountService talks to AccountWebAPI.

Your question suggests that the use of microservices might not be a thought out, educated choice here. Microservices are separation of responsibility taken to the extreme. They should be independently deployable and share as few things as possible. I also suggest you model your subdomains and Bounded Contexts (big business areas) first. Microservices will naturally fall into one of the BCs.