net core-框架设计

一，杂谈-理论  参考 https://www.cnblogs.com/davenkin/p/ddd-coding-practices.html

　　1 基于“Service + 贫血模型”的实现：

            主要的特点是：存在一个贫血的“领域对象”，业务逻辑通过一个Service类实现，然后通过setter方法更新领域对象。如果没有ORM，实体类都没有必要存在。这种方式依然是一种面向过程的编程范式，违背了最基本的OO原则。另外的问题在于职责划分模糊不清，使本应该内聚在Order中的业务逻辑泄露到了其他地方(OrderService)，导致Order成为一个只是充当数据容器的贫血模型(Anemic Model)，而非真正意义上的领域模型。在项目持续演进的过程中，这些业务逻辑会分散在不同的Service类中，最终的结果是代码变得越来越难以理解进而逐渐丧失扩展能力。

     2. 基于事务脚本的实现

 　　在上一种实现方式中，我们会发现领域对象(Order)存在的唯一目的其实是为了让ORM这样的工具能够一次性地持久化，在不使用ORM的情况下，领域对象甚至都没有必要存在。于是，此时的代码实现便退化成了事务脚本(Transaction Script)，也就是直接将Service类中计算出的结果直接保存到数据库(或者有时都没有Service类，直接通过SQL实现业务逻辑)，我也写过直接在接口层调用sql完成业务逻辑的处理:

public void changeProductCount(String id, ChangeProductCountCommand command) {
        OrderStatus orderStatus = DAO.getOrderStatus(id);
        if (orderStatus == PAID) {
            throw new OrderCannotBeModifiedException(id);
        }
        DAO.updateProductCount(id, command.getProductId(), command.getCount());
        DAO.updateTotalPrice(id);
    }

可以看到，DAO中多出了很多方法，此时的DAO不再只是对持久化的封装，而是也会包含业务逻辑。另外，DAO.updateTotalPrice(id)方法的实现中将直接调用SQL来实现Order总价的更新。与“Service+贫血模型”方式相似，事务脚本也存在业务逻辑分散的问题。

　　事实上，事务脚本并不是一种全然的反模式，在系统足够简单的情况下完全可以采用。但是：一方面“简单”这个度其实并不容易把握；另一方面软件系统通常会在不断的演进中加入更多的功能，使得原本简单的代码逐渐变得复杂。因此，事务脚本在实际的应用中使用得并不多。

 　　3 基于领域对象的实现

　　在这种方式中，核心的业务逻辑被内聚在行为饱满的领域对象(Order)中，实现Order类如下：

public void changeProductCount(ProductId productId, int count) {
        if (this.status == PAID) {
            throw new OrderCannotBeModifiedException(this.id);
        }
        OrderItem orderItem = retrieveItem(productId);
        orderItem.updateCount(count);
    }

　　然后在Controller或者Service中，调用Order.changeProductCount()：

public void changeProductCount(@PathVariable(name = "id") String id, @RequestBody @Valid ChangeProductCountCommand command) {
        Order order = DAO.byId(orderId(id));
        order.changeProductCount(ProductId.productId(command.getProductId()), command.getCount());
        order.updateTotalPrice();
        DAO.saveOrUpdate(order);
    }

待续。。以后有新的感悟来补充。