eShopOnWeb 知多少

Posted 2021-01-05 『___知多少』

1.引言

eShopOnWeb是基于ASP.NET Core构建，官方创建这样一个示例项目的目的，我想无非以下几点：

1. 推广ASP.NET Core
2. 指导利用ASP.NET Core如何进行架构设计
3. 普及架构设计思想

eShopOnWeb?与另外一个eShopOnContainers互相补充。eShopOnContainers是基于微服务和容器技术的应用程序架构，支持多重部署。而eShopOnWeb相较于它就简单的多，其是基于传统Web应用开发，仅支持单一部署。

本文就简单梳理下自己的所学所得。

2.MPA Or SPA

eShopOnWeb的示例项目中包含两个Web项目，一个是基于MVC创建的MPA多页面应用，一个是基于Razor创建的SPA单页面应用。在此之间我该如何选择呢？

1. 是否需要丰富的交互行为？
2. 是否足够的前端技术积累？
3. 是否主要通过API进行交互？

3. 架构设计

eShopOnWeb中应用了DDD和整洁架构的部分思想，值得了解一下。

3.1 架构原则

关注点分离：简称SOP。在分层架构设计中，关注点分离是核心设计思想，每一层独自负责不同的职责。从架构上讲，可以通过将核心业务与基础设施和用户界面逻辑分离来实现。该原则旨在避免紧耦合，又可确保各个模块独立发展。

封装：封装的是什么？是对象的状态和行为。外部对象无需关注其内部的实现机制。
在类中，通过使用访问修饰符来限制外部的访问来实现封装。 如果外部想要操纵对象的状态，它应该通过定义良好的函数（或属性设置器）来实现，而不是直接访问对象的私有状态。
而不同模块之间通过公开定义良好的接口进行方法调用，来实现封装。以隔离内部的实现机制。通过封装来确保应用程序间不同部分之间的隔离，正确使用封装有助于在应用程序设计中实现松耦合和模块化。

依赖倒置：简称DIP。高层模块不应该依赖低层模块，均应该依赖与抽象；抽象不应该依赖于细节；细节应该依赖于抽象。DIP是构建松耦合应用的关键部分，从而确保应用程序模块化，更易于测试和维护。 通过遵循DIP，可以应用依赖注入。

显式依赖：方法和类应明确指定所需的协作对象（依赖）以确保正常运行。简单来说，对于类而言，提供明确的构造函数（即在构造函数参数中指定该类需要正常工作所需的依赖对象），以便调用者正确传参以正确实例化对象。

单一职责：简称SRP。SRP作为面向对象设计的原则之一，也适用于架构原则。其与SOP类似。它强调对象应该只有一个责任，他们只应该仅有一个改变的理由。换言之，对象应该改变的唯一情况是它的职责需要被更新。遵守该原则，可以编写松耦合和模块化的应用。因为大量的新的行为都应该创建新类去实现，而不是添加到已经存在的类中。添加新类永远比修改一个类安全，因为尚无代码依赖于新类。
在复杂的大型应用中，可以将SRP应用到分层应用的各个层。展现职责应保留在UI项目中，而数据访问职责应保留在基础设施项目中， 业务逻辑应该保留在应用程序核心项目中。如此，即易于测试又可以独立于其他职责持续演化。
该原则的更高级应用，就是微服务了。每个微服务负责独立的职责。

摒弃重复：当出现重复时，应该实施重构。避免当功能改进时，需要同时修改多个部分。

透明持久化：要求可以轻松切换持久化技术，而实现持久化无感知（透明持久化）。

限界上下文：该概念是DDD战略设计的一部分，通过限界上下文来划分领域，作为领域的显式边界，为领域提供上下文语境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。

3.2. 传统分层架构和整洁架构

传统的分层架构是大家所熟知的三层架构。

这样的架构的缺点是：

1. 依赖关系由上至下，不易解耦
2. 不易测试，需要测试数据库

那如何解决三层架构的问题呢，借助【依赖倒置原则】。
DDD的分层架构思想和整洁架构中都是借助【依赖倒置原则】实现层与层之间强依赖关系的解耦。我们来看下整洁架构：

从该洋葱视图中我们可以看到：

1. 依赖关系由外而内。
2. 处于核心的是实体和接口，不依赖任何其他项。其次是领域服务，仅依赖实体和接口，也相对独立。它们统称为应用程序内核。
3. 应用程序内核之外是基础架构层和展现层，彼此也不一定依赖。

由于应用程序内核不依赖于基础设施层，所以可以很容易编写单元测试。

由于UI层也不直接依赖于基础设施层，所以我们可以轻松置换基础设施层的实现（比如使用内存数据库），以进行集成测试。

下面我们就来看看eShopOnWeb是如何应用整洁架构的。

4. 项目结构

首先我们看下模板架构的项目结构。

从上图来看其项目结构十分简单，简单的三层，加上三个测试项目。
三层对应：

1. ApplicationCore：领域层
2. Infrastructure：基础设施层
3. Web/WebRazorPages：展现层

其实该项目架构是DDD经典四层架构，只不过其将应用层集成到展现层中去了。

4.1 基础设施层

主要提供通用的基础服务和持久化。

从上图的代码结构我们可以看出：

1. 在Data文件夹下定义了用于持久化的商品目录数据库上下文CatalogContext和泛型仓储EfRepository。
2. Identity文件夹下定义了身份数据库上下文的。
3. Logging文件夹定义了一个日志适配器。
4. Services定义了一个通用的邮件发送基础服务。

4.2. 领域层

领域层是一个项目的核心，用来定义业务规则并实现。其主要用来实体、值对象、聚合、仓储、领域服务和领域事件等。

从上图来看：

1. Entities文件夹下定义了三个聚合根和相关的实体及值对象。
2. Exceptions文件夹定义了公共的异常。
3. Interfaces文件夹定义了系列接口。
4. Services文件夹定义了两个领域服务。
5. Specifications文件夹下是实现的规约模式。

4.2.1. 聚合根的相关实现

这里我们来看下聚合根的相关定义和实现。

///抽象的聚合根空接口
public interface IAggregateRoot
    { }
//所有的实体基类
public class BaseEntity
    {
        public int Id { get; set; }
    }

//购物车聚会根
public class Basket : BaseEntity, IAggregateRoot
{
    public string BuyerId { get; set; }
    private readonly List<BasketItem> _items = new List<BasketItem>();
    public IReadOnlyCollection<BasketItem> Items => _items.AsReadOnly();

    public void AddItem(int catalogItemId, decimal unitPrice, int quantity = 1)
    {
        if (!Items.Any(i => i.CatalogItemId == catalogItemId))
        {
            _items.Add(new BasketItem()
            {
                CatalogItemId = catalogItemId,
                Quantity = quantity,
                UnitPrice = unitPrice
            });
            return;
        }
        var existingItem = Items.FirstOrDefault(i => i.CatalogItemId == catalogItemId);
        existingItem.Quantity += quantity;
    }
}

从这个实现中我们可以学习到：

通过定义一个空的接口IAggregateRoot，要求所有的聚会根来实现它。

这样做的体现了什么思想：

1. 面向接口编程
2. 约定大于配置
3. 依赖注入

通过定义一个BaseEntity，要求所有的实体继承它。

为什么这样做？

1. 因为实体的特征是具有唯一的身份标识，所以通过在父类来定义Id属性来实现。这也就是层超类型的实现方式。

这样做有什么缺点？
因为所有实体的主键类型不一定都是int类型，所以这个基类型最好改成泛型。

Basket聚合根中将Items定位为Readonly，是为了封装集合，避免子项被其他地方更改。

4.2.2. 仓储的相关实现

仓储是用来透明持久化领域对象的。

public interface IRepository<T> where T : BaseEntity
{
    T GetById(int id);
    T GetSingleBySpec(ISpecification<T> spec);
    IEnumerable<T> ListAll();
    IEnumerable<T> List(ISpecification<T> spec);
    T Add(T entity);
    void Update(T entity);
    void Delete(T entity);
}
public interface IAsyncRepository<T> where T : BaseEntity
{
    Task<T> GetByIdAsync(int id);
    Task<List<T>> ListAllAsync();
    Task<List<T>> ListAsync(ISpecification<T> spec);
    Task<T> AddAsync(T entity);
    Task UpdateAsync(T entity);
    Task DeleteAsync(T entity);
}

从以上代码我们可以学到两点：

1. 面向接口编程
2. 职责分离，同步异步接口分离。

4.2.3. 领域服务相关实现

领域服务用来实现业务逻辑的。

public interface IOrderService
{
    Task CreateOrderAsync(int basketId, Address shippingAddress);
}
public class OrderService : IOrderService
{
    private readonly IAsyncRepository<Order> _orderRepository;
    private readonly IAsyncRepository<Basket> _basketRepository;
    private readonly IAsyncRepository<CatalogItem> _itemRepository;
    public OrderService(IAsyncRepository<Basket> basketRepository,
        IAsyncRepository<CatalogItem> itemRepository,
        IAsyncRepository<Order> orderRepository)
    {
        _orderRepository = orderRepository;
        _basketRepository = basketRepository;
        _itemRepository = itemRepository;
    }
    public async Task CreateOrderAsync(int basketId, Address shippingAddress)
    {
        var basket = await _basketRepository.GetByIdAsync(basketId);
        Guard.Against.NullBasket(basketId, basket);
        var items = new List<OrderItem>();
        foreach (var item in basket.Items)
        {
            var catalogItem = await _itemRepository.GetByIdAsync(item.CatalogItemId);
            var itemOrdered = new CatalogItemOrdered(catalogItem.Id, catalogItem.Name, catalogItem.PictureUri);
            var orderItem = new OrderItem(itemOrdered, item.UnitPrice, item.Quantity);
            items.Add(orderItem);
        }
        var order = new Order(basket.BuyerId, shippingAddress, items);
        await _orderRepository.AddAsync(order);
    }

从以上代码我们可以学习到：

1. 依赖注入
2. 领域服务负责实现真正的业务逻辑

4.3. 应用层和展现层

如上面所阐述，在示例项目中应用层和展现层合二为一。应用层负责展现层与领域层之间的协调，协调业务对象来执行特定的应用程序。

5. 面向切面编程（AOP）

eShopOnWeb中也提到了AOP，介绍了在ASP.NET Core中如何应用过滤器来进行AOP，比如：身份验证、模型验证、输出缓存和错误处理等。

5. 简明DDD

在eShopOnWeb中，也对DDD的概念，是否使用，何时使用，何时不用，都略有介绍。这里就摘录一二，当然也可以参考我之前的写的DDD理论学习系列。

结论

1. DDD首先是一个方法论，其注重于领域的合理建模，分为战略建模和战术建模。
2. 如果你不知道你需要它，那么你可能不需要它。
3. 如果你不知道到DDD用于解决什么问题，那么你可能没有遇到这些问题。
4. DDD倡导者也经常指出其仅适用于大型项目 （>6个月）。

相关概念

1. DDD是用来对真实世界系统或流程的建模。
2. 使用DDD时，你需要和领域专家紧密合作，领域专家能够解释真实的系统该如何运行。在和领域专家的交流中确定通用语言，其主要用来描述系统中的一些概念。而之所以是通用，是因为不管是开发人员还是领域专家都应能够读懂。而通用语言描述的概念将构成面向对象设计的基础。其体现在代码中的理想状态是代码即设计。

战术

1. 值对象：不可变。
2. 实体：具有唯一标识符可变。
3. 聚会根：在DDD中，用来表示整体与部分的关系，聚合是将相关联的领域对象进行显式分组，来表达整体的概念（也可以是单一的领域对象）。比如将表示订单与订单项的领域对象进行组合，来表达领域中订单这个整体概念。
4. 仓储：一种持久化的模式，用于隔离具体持久化措施，实现透明持久化。
5. 工厂：用于对象的创建。
6. 服务：应用服务和领域服务。领域服务负责业务逻辑，应用服务用于表达业务用例和用户故事。

战略

1. 限界上下文：来为领域提供上下文语境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
2. 上下文映射图：限界上下文之间的关联关系。

6. 应用测试

在eShopOnWeb中，还示例了三个测试项目，来指导我们合理的进行测试。

7. 总结

总体而言，示例项目简单容易理解，也主要是为了便于推广和演示。但里面涉及的知识点并没有想象的那么简单，从架构原则到设计和应用，每一个环节都包含不简单的知识体系。

所以等什么呢？结合示例项目和官方文档使用 ASP.NET Core 和 Azure 构建新式 Web 应用程序开始学习吧，相信你也会收获颇丰。