1

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

1) 我可以消除ProductService并在CustomerAccountController本身中编排订单的检索吗?这是因为我将控制器视为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) 
   } 
}

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

层:

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

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

4

2 回答 2

6

这些名称AccountServiceProductService暗示您违反了单一职责原则开放封闭原则接口隔离原则。这三个原则加在一起是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 回答