我违反了SOLID原则和n层微服务架构吗?

won*_*rld 2 c# domain-driven-design n-layer solid-principles

在以下示例中,AccountServiceProductService位于ASP.NET MVC应用程序中.该AccountWebAPIProductWebAPI是外部托管API的微服务.

1)我可以消除ProductService并协调检索CustomerAccountController本身的订单吗?这是因为我将Controller视为DDD(域驱动设计)中提到的应用层/服务.

2)我是否违反了n层架构,因为ProductService调用的AccountService是同一层?

3)由于AccountWebAPIProductWebAPI微服务,它们是否必须在客户端应用程序(MVC App)中作为AccountServiceProductService分开,以保持责任分离?因此,ProductService需要重命名为ProductAppService,ProductService应该与ProductWebAPI交互,就像AccountServiceAccountWebAPI的对话一样.

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) 
   } 
}
Run Code Online (Sandbox Code Playgroud)

更新:我意识到OrderService将是订单的适当服务名称,而不是ProductService.

层:

视图 - 控制器 - 服务 - WebAPIs - 域 - 存储

OrderView - CustomerAccountController - ProductService(在同一层中调用AccountService) - ProductWebAPI - ProductDomain - ProductRepository

Ste*_*ven 5

这些名称AccountServiceProductService暗示您违反了单一责任原则,开放封闭原则接口隔离原则,这是SOLID原则的 60%.

本文解释了这个问题的原因,但简而言之:

违反单一责任原则,因为每个类别的方法都没有高度凝聚力.与这些方法相关的唯一事实是它们属于同一个概念或实体.

该设计违反了开放/封闭原则,因为几乎每次[方法]被添加到系统中时,都需要更改现有接口及其实现.每个接口至少有两个实现:一个实际实现和一个测试实现.

违反了接口隔离原则,因为接口[例如IProductService]很宽(有很多方法),并且这些接口的使用者被迫依赖于他们不使用的方法.

解决方案是为每个用例提供自己的类.这里这里详细解释了这种设计.

我甚至会说具有相同结构的Web API控制器导致相同类型的SOLID违规.实际上,如果您应用文章给出的设计,您可以完全删除所有Web API控制器,并将其替换为能够传递消息的单个基础结构逻辑.这里描述这样的设计(本文主要讨论WCF,但它也适用于Web API,并且可以在文章链接到的示例项目中看到Web API的工作示例).