1

在以下示例中，AccountService和ProductService位于 ASP.NET MVC 应用程序中。AccountWebAPI和ProductWebAPI是外部托管的API微服务。

1) 我可以消除ProductService并在CustomerAccountController本身中编排订单的检索吗？这是因为我将控制器视为DDD（域驱动设计）中提到的应用层/服务。

2）我是否违反了n层架构，因为ProductService调用了同一层的AccountService ？

3）由于AccountWebAPI和ProductWebAPI是微服务，它们是否必须在客户端应用程序（MVC App）中分离为AccountService和ProductService以保持职责分离？所以ProductService需要重命名为ProductAppService并且ProductService应该与ProductWebAPI交互，就像AccountService与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) 
   } 
}

更新：我意识到OrderService将是订单的适当服务名称，而不是ProductService。

层：

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

OrderView -- CustomerAccountController -- ProductService（同层调用AccountService） -- ProductWebAPI -- ProductDomain -- ProductRepository

4

2 回答 2

6

这些名称AccountService和ProductService暗示您违反了单一职责原则、开放封闭原则和接口隔离原则。这三个原则加在一起是SOLID 原则的 60% 。

本文解释了这样做的原因，但简而言之：

单一职责原则被违反，因为每个类中的方法不是高度内聚的。与这些方法相关的唯一事实是它们属于同一概念或实体。

该设计违反了开放/封闭原则，因为几乎每次将[方法]添加到系统时，都需要更改现有接口及其实现。每个接口至少有两种实现：一种是真实实现，一种是测试实现。

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

解决方案是为每个用例提供自己的类。此设计在此处和此处进行了详细说明。

我什至会说拥有相同结构的 Web API 控制器会导致相同类型的 SOLID 违规。事实上，如果您应用文章中给出的设计，您可以完全移除所有 Web API 控制器，并将它们替换为能够传递消息的单个基础架构逻辑。此处描述了这种设计（本文主要讨论 WCF，但它也适用于 Web API，并且可以在文章链接的示例项目中看到 Web API 的工作示例）。

于 2015-11-01T08:50:17.077 回答
3

1) 我可以消除 ProductService 并在 CustomerAccountController 本身中编排订单的检索吗？

你可以这样做，但这意味着你会将交付逻辑与应用逻辑混为一谈。这不是最严重的 SRP 违规，但会取消为同一用例添加第二个交付机制（Web API 以外的其他机制）的选项。不过，在某些情况下，这可能是一个有效的权衡。

2）我是否违反了n层架构，因为ProductService调用了同一层的AccountService？

绝对不。架构是一组约束性的技术决策。违反架构的唯一方法是建立第二个并行架构，该架构以某种方式破坏了原始架构的原则。在这里，您甚至不会违反 n 层方法，因为其中没有任何内容表明您不应该调用同一层中的某人。

3）由于AccountWebAPI和ProductWebAPI是微服务，在客户端应用程序（MVC App）中是否必须将它们分开为AccountService和ProductService，以保持职责分离？所以 ProductService 需要重命名为 ProductAppService 并且 ProductService 应该只与 ProductWebAPI 交互，就像 AccountService 与 AccountWebAPI 对话一样。

您的问题表明，使用微服务可能不是一个经过深思熟虑的、受过教育的选择。微服务将责任分离发挥到了极致。它们应该是可独立部署的，并且共享尽可能少的东西。我还建议您首先对子域和限界上下文（大业务领域）进行建模。微服务自然会落入 BC 中。

于 2015-11-02T09:49:51.567 回答