【DDD领域】领域驱动设计论述

1.初步认识

笔者因为工作原因由传统的mvc架构转入到ddd领域架构，先说一下ddd领域的不同之处：
1.ddd首先需要对这个业务分析，完全理解整个业务，将业务划分为不同的业务域如房间领域（床，窗子，板凳）然后创建领域对象，这个和传统mvc不同，mvc的方式为直接创建类，mvc一般通过代码生成器生成相关的service，controller，持久层，在通过代码里的service设置各个类之间的业务逻辑。相对来说（ddd逻辑更加简单，后期更容易维护，但要求后端的抽象能力要求更高）。
2.ddd（Domain Driven Design），分为四个层次1API层（controller）2应用层（app）3领域层（domain）4基础层（infra）

（如图，ddd每个业务如同相互独立的金字塔一样分开，需要用的时候就去往不同的金字塔）

(如图，mvc类似于篮球，虽然类名包名不同，但是业务逻辑耦合，你中有我我中有你)

2.ddd结构及数据封装

2.1.infra层

数据持久层
对数据库进行操作，或放置基础组件。

2.2.domain层

领域层
划分不同的业务领域，对领域的定义。依赖infra层。

2.3.app层

业务层
相关业务代码，主要做业务。依赖infra层，domain层。

2.4.controller层

api层
提供相关的访问接口。依赖app层。

2.5.数据封装

数据封装	简要说明
BO（Business Object）	指业务对象，代表系统中的业务实体或业务对象模型
VO（Value Object）	指值对象，用于传输数据和封装一组相关的数据。查询返回结果
PO（Persistence Object）	持久化对象是指那些能够存储在数据库中的对象
Cmd（Command）	指命令对象，用于表示执行某些操作或动作的命令
DTO（Data Transfer Object）	是一种用于在不同层或系统之间传输数据的对象

数据转化顺序一般为：
cmd->bo->领域对象->po（数据储存）
cmd->vo（查询返回）

3.贫血模式与充血模式

3.1 贫血模式

特点：
1.数据与业务逻辑分离：在贫血模型中，业务逻辑通常被分离到服务层或控制器层中，领域对象（模型类）只包含属性（数据）和简单的getter/setter方法。
2.缺少行为：领域对象本身没有业务行为，仅作为数据容器存在。

优点：
1简单易懂：由于领域对象只包含数据，理解和实现起来相对简单。
分层清晰：业务逻辑与数据模型分离，职责明确。
缺点：
违反面向对象原则：特别是违反了“封装”和“高内聚”的原则，因为对象不具有操作自己数据的能力。
维护困难：业务逻辑分散在多个服务中，当业务需求变更时，可能需要在多个地方进行修改，增加了维护难度。
代码举例：
entity

public class Product {
    private String id;
    private String name;
    private double price;
    private int quantity;

    // Constructor
    public Product(String id, String name, double price, int quantity) {
        this.id = id;
        this.name = name;
        this.price = price;
        this.quantity = quantity;
    }

    // Getters and Setters
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }

    public int getQuantity() {
        return quantity;
    }

    public void setQuantity(int quantity) {
        this.quantity = quantity;
    }
}

service

public class ProductService {

    // Method to calculate the total price of products
    public double calculateTotalPrice(Product product) {
        return product.getPrice() * product.getQuantity();
    }

    // Method to update the quantity of a product
    public void updateQuantity(Product product, int quantity) {
        product.setQuantity(quantity);
    }
}

main

public class Main {
    public static void main(String[] args) {
        // Create a new product
        Product product = new Product("1", "Laptop", 1000.0, 5);

        // Create a product service
        ProductService productService = new ProductService();

        // Calculate the total price of the product
        double totalPrice = productService.calculateTotalPrice(product);
        System.out.println("Total Price: " + totalPrice);

        // Update the quantity of the product
        productService.updateQuantity(product, 10);
        System.out.println("Updated Quantity: " + product.getQuantity());
    }
}

3.2 充血模式

特点：
1.数据与业务逻辑结合：在充血模型中，领域对象不仅包含属性，还包含与这些数据相关的业务逻辑和行为。
2.高内聚：对象自身具有操作自己数据的能力，业务逻辑直接放在领域对象内部。

优点：
1.面向对象原则：符合封装和高内聚的原则，使代码更加符合面向对象设计的思想。
2.维护方便：业务逻辑集中在领域对象中，当业务需求变更时，只需修改相关的领域对象即可，维护更为方便。
缺点：
1.复杂度增加：领域对象变得复杂，可能会导致对象职责过重。
2.学习曲线陡峭：开发人员需要更深入地理解领域和面向对象设计原则，增加了学习难度。

适用场景
贫血模式适用于：简单的CRUD应用，业务逻辑较为简单，变更较少的场景。
充血模式适用于：复杂的业务系统，需要严格遵循领域驱动设计，业务逻辑复杂且频繁变化的场景。
代码示例
entity：

public class Product {
    private String id;
    private String name;
    private double price;
    private int quantity;

    // Constructor
    public Product(String id, String name, double price, int quantity) {
        this.id = id;
        this.name = name;
        this.price = price;
        this.quantity = quantity;
    }

    // Getters and Setters
    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public double getPrice() {
        return price;
    }

    public void setPrice(double price) {
        this.price = price;
    }

    public int getQuantity() {
        return quantity;
    }

    public void setQuantity(int quantity) {
        this.quantity = quantity;
    }

    // Business Logic Method: Calculate total price
    public double calculateTotalPrice() {
        return this.price * this.quantity;
    }

    // Business Logic Method: Update quantity
    public void updateQuantity(int quantity) {
        this.quantity = quantity;
    }

    // Business Logic Method: Apply discount
    public void applyDiscount(double discountPercentage) {
        this.price = this.price * (1 - discountPercentage / 100);
    }
}

main：

public class Main {
    public static void main(String[] args) {
        // Create a new product
        Product product = new Product("1", "Laptop", 1000.0, 5);

        // Calculate the total price of the product
        double totalPrice = product.calculateTotalPrice();
        System.out.println("Total Price: " + totalPrice);

        // Update the quantity of the product
        product.updateQuantity(10);
        System.out.println("Updated Quantity: " + product.getQuantity());

        // Apply a discount to the product
        product.applyDiscount(10);
        System.out.println("Discounted Price: " + product.getPrice());
    }
}

4.总结

归根结底，ddd领域驱动其实也就是一种对软件的业务划分开发方法，每一个人对ddd的理解都有所不同，领域驱动对于业务理解和后期维护有极大的改良。