万字长文+示例代码详解DDD中常用的架构(含代码示例)

目录

分层架构(Layered Architecture)

概念

示例代码

总结

领域驱动设计的六边形架构(Hexagonal Architecture)

概念

示例代码

总结

CQRS(Command Query Responsibility Segregation)

概念

示例代码

总结

微服务架构(Microservices Architecture)

概念

示例代码

总结

领域事件驱动架构(Domain Event-Driven Architecture)

概念

示例代码

总结

如何选择?


分层架构(Layered Architecture)

概念

分层架构是一种常见的架构模式,将应用程序分为不同的层次,每个层次有特定的职责。典型的分层架构包括表示层(Presentation Layer)、应用层(Application Layer)、领域层(Domain Layer)和基础设施层(Infrastructure Layer)。分层架构能够将关注点分离,提高系统的可维护性和可扩展性。

常见的分层架构通常包括以下几个层次:

  1. 表示层(Presentation Layer):表示层负责处理用户界面和用户交互。它可以是Web界面、移动应用程序界面或其他用户界面。表示层负责接收用户的请求,将其转发给应用层进行处理,并将应用层的响应反馈给用户。

  2. 应用层(Application Layer):应用层是系统的核心,负责协调业务逻辑的执行。它接收来自表示层的请求,将请求转化为适当的领域操作,并协调领域层的对象进行处理。应用层不包含具体的业务逻辑,而是将业务逻辑委托给领域层。

  3. 领域层(Domain Layer):领域层包含系统的核心业务逻辑和领域模型。它包含了领域对象、实体、值对象以及领域服务。领域层负责实现业务规则、验证和状态变更等核心领域逻辑。

  4. 基础设施层(Infrastructure Layer):基础设施层提供与外部系统的交互,如数据库、文件系统、消息队列等。它包含了各种技术实现和框架,用于支持应用程序的运行。基础设施层还可以包括数据访问层、消息传递层、日志记录等。

示例代码

举一个栗子,如下:

// 表示层
public class UserController {
    private UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    public void createUser(String name, String email, String password) {
        // 处理用户创建请求
        userService.createUser(name, email, password);
        // 返回响应给用户
    }

    // 其他用户相关操作的方法
}

// 应用层
public class UserService {
    private UserRepository userRepository;
    // 可能还有其他依赖注入的服务或组件

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void createUser(String name, String email, String password) {
        // 执行业务逻辑,如验证、密码加密等
        User user = new User(name, email, password);
        userRepository.save(user);
    }

    // 其他用户相关操作的方法
}

// 领域层
public class User {
    private String name;
    private String email;
    private String password;

    public User(String name, String email, String password) {
        // 属性赋值和验证等逻辑
    }

    // 其他领域逻辑和操作的方法
}

// 基础设施层
public class UserRepository {
    public void save(User user) {
        // 将用户保存到数据库
    }

    // 其他数据库操作的方法
}

// 在应用程序的入口点或配置中,组装和注入各个层次的对象
public class Application {
    public static void main(String[] args) {
        UserRepository userRepository = new UserRepository();
        UserService userService = new UserService(userRepository);
        UserController userController = new UserController(userService);

        // 启动应用程序,处理用户请求等
    }
}

将应用程序分为表示层、应用层、领域层和基础设施层。每个层次都有明确的职责,表示层处理用户界面和交互,应用层协调业务逻辑的执行,领域层包含核心业务逻辑和领域模型,基础设施层处理与外部系统的交互。

总结

通过分层架构,我们可以将关注点分离,使代码更易于维护、测试和扩展。每个层次可以独立变化,而不会对其他层次产生过多影响。这种组织方式可以帮助我们更好地遵循领域驱动设计的原则,并支持清晰的代码组织和职责划分。

领域驱动设计的六边形架构(Hexagonal Architecture)

概念

领域驱动设计的六边形架构(Hexagonal Architecture),也被称为端口和适配器模式(Ports and Adapters Pattern),是一种用于构建可测试、可扩展和松耦合系统的架构模式。它强调将领域模型作为核心,并将其与外部系统隔离开来,以便更好地实现领域模型的独立演化。

在六边形架构中,系统被视为一个六边形,核心领域模型位于中心,与外部系统通过适配器(Adapter)进行交互。领域模型定义了系统的核心业务逻辑和领域对象,而适配器负责将外部系统与领域模型连接起来。

示例代码

// 领域模型
public class Product {
    private String name;
    private String description;
    private BigDecimal price;

    // 构造函数、属性和方法等
}

// 适配器接口
public interface ProductRepository {
    void save(Product product);
    Product getById(String id);
    List getAll();
    // 其他与数据存储相关的方法
}

// 适配器实现
public class InMemoryProductRepository implements ProductRepository {
    private Map productMap = new HashMap<>();

    @Override
    public void save(Product product) {
        productMap.put(product.getId(), product);
    }

    @Override
    public Product getById(String id) {
        return productMap.get(id);
    }

    @Override
    public List getAll() {
        return new ArrayList<>(productMap.values());
    }
}

// 领域服务接口
public interface ProductService {
    void createProduct(String name, String description, BigDecimal price);
    Product getProductById(String id);
    List getAllProducts();
    // 其他领域服务方法
}

// 领域服务实现
public class ProductServiceImpl implements ProductService {
    private ProductRepository productRepository;

    public ProductServiceImpl(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Override
    public void createProduct(String name, String description, BigDecimal price) {
        Product product = new Product(name, description, price);
        productRepository.save(product);
    }

    @Override
    public Product getProductById(String id) {
        return productRepository.getById(id);
    }

    @Override
    public List getAllProducts() {
        return productRepository.getAll();
    }

    // 其他领域服务方法的实现
}

// 在应用程序的入口点或配置中,组装和注入适配器和领域服务
public class Application {
    public static void main(String[] args) {
        ProductRepository productRepository = new InMemoryProductRepository();
        ProductService productService = new ProductServiceImpl(productRepository);

        // 启动应用程序,使用领域服务进行业务操作
    }
}

在上面的栗子中,我们有一个核心的领域模型Product,它表示产品实体。然后,我们定义了适配器接口ProductRepository,它定义了与数据存储相关的操作。InMemoryProductRepository是一个适配器的实现,它使用内存来存储产品数据。在领域服务方面,我们定义了ProductService接口,它提供了对产品领域的操作。ProductServiceImpl是领域服务的具体实现,它依赖于ProductRepository适配器进行数据存储。领域模型和领域服务就位于系统的核心位置,与外部系统通过适配器进行交互。

总结

六边形架构的优势在于它的灵活性和可测试性。通过将领域模型与外部系统隔离开来,我们可以独立地测试领域逻辑,并对外部系统进行模拟或替代。此外,六边形架构还支持领域模型的独立演化,使系统更具灵活性和可扩展性。

CQRS(Command Query Responsibility Segregation)

概念

CQRS 是一种将读操作(Query)和写操作(Command)分离的架构模式。它通过将读模型和写模型分开来优化系统的可扩展性和性能。在 CQRS 中,读操作可以通过专门的查询模型进行处理,而写操作则由领域模型负责。

在传统的 CRUD(Create, Read, Update, Delete)模式中,通常将读写操作合并在同一个接口或服务中。而在 CQRS 中,将读操作和写操作分离为独立的接口和服务,分别针对不同的需求进行优化。

示例代码

// Command 模型
public class CreateUserCommand {
    private String name;
    private String email;
    private String password;

    // 构造函数、属性和方法等
}

// Command 处理器
public class UserCommandHandler {
    public void handleCreateUserCommand(CreateUserCommand command) {
        // 执行创建用户的业务逻辑,包括验证、密码加密等
        User user = new User(command.getName(), command.getEmail(), command.getPassword());
        // 将用户保存到数据库或事件日志等
    }

    // 其他 Command 处理器的方法
}

// Query 模型
public class GetUserQuery {
    private String userId;

    // 构造函数、属性和方法等
}

// Query 处理器
public class UserQueryHandler {
    public User handleGetUserQuery(GetUserQuery query) {
        // 查询用户的业务逻辑,可能涉及数据库查询、缓存等
        User user = // 从数据库或缓存中获取用户信息
        return user;
    }

    // 其他 Query 处理器的方法
}

// 在应用程序的入口点或配置中,组装和注入 Command 处理器和 Query 处理器
public class Application {
    public static void main(String[] args) {
        UserCommandHandler commandHandler = new UserCommandHandler();
        UserQueryHandler queryHandler = new UserQueryHandler();

        // 启动应用程序,处理命令和查询
    }
}

代码中,Command 模型和对应的 Command 处理器,用于处理写操作。CreateUserCommand表示创建用户的命令,UserCommandHandler负责处理该命令并执行相应的业务逻辑。Query 模型和对应的 Query 处理器,用于处理读操作。GetUserQuery表示获取用户的查询,UserQueryHandler负责处理该查询并返回相应的结果。

总结

CQRS 的优势在于它能够根据不同的操作类型进行优化,提高系统的性能和可伸缩性。通过将读写操作分离,可以针对不同的操作类型采用不同的数据存储和处理方式。此外,CQRS 还能够帮助实现更好的领域模型设计,使系统更加灵活和可扩展。

微服务架构(Microservices Architecture)

概念

微服务架构是一种将应用程序拆分为一组小型、独立部署的服务的架构模式。每个微服务都专注于某个特定的业务领域,并通过轻量级的通信机制进行交互。微服务架构有助于团队的自治性和系统的可扩展性,但也增加了系统的复杂性。

微服务架构的主要特点包括:

  1. 服务拆分:应用程序被拆分为多个小型服务,每个服务具有清晰的边界和独立的责任。

  2. 独立部署:每个服务可以独立地进行开发、测试、部署和扩展,不会影响其他服务。

  3. 松耦合通信:服务之间使用轻量级的通信机制进行通信,如RESTful API、消息队列等。

  4. 基础设施自治:每个服务可以选择适合自身需求的技术栈和基础设施,不受其他服务的限制。

示例代码

// 用户服务
public class UserService {
    public User createUser(String name, String email) {
        // 创建用户的业务逻辑
        User user = new User(name, email);
        // 保存用户到数据库
        return user;
    }

    public User getUserById(String userId) {
        // 根据用户ID查询用户的业务逻辑
        // 从数据库或缓存中获取用户信息
        return user;
    }
    
    // 其他用户相关的业务逻辑和操作方法
}

// 订单服务
public class OrderService {
    public Order createOrder(String userId, List products) {
        // 创建订单的业务逻辑
        User user = userService.getUserById(userId);
        // 根据产品信息计算订单金额等
        Order order = new Order(user, products);
        // 保存订单到数据库
        return order;
    }

    public Order getOrderById(String orderId) {
        // 根据订单ID查询订单的业务逻辑
        // 从数据库或缓存中获取订单信息
        return order;
    }
    
    // 其他订单相关的业务逻辑和操作方法
}

// 在应用程序的入口点或配置中,组装和注入各个微服务对象
public class Application {
    public static void main(String[] args) {
        UserService userService = new UserService();
        OrderService orderService = new OrderService(userService);

        // 启动应用程序,处理用户请求等
    }
}

两个微服务:用户服务(UserService)和订单服务(OrderService)。每个服务都有自己的业务逻辑和操作方法,并通过依赖注入的方式组装和协调。微服务之间可以使用RESTful API或其他通信机制进行通信。例如,在订单服务中,我们通过调用用户服务的getUserById方法来获取用户信息。

总结

通过微服务架构,我们可以将大型应用程序拆分为多个小型服务,每个服务专注于特定的业务功能。这样做有助于提高系统的灵活性、可伸缩性和可维护性,同时也可以加快开发速度和团队的独立性。

需要注意的是,微服务架构需要仔细考虑服务之间的边界、通信机制、数据一致性等方面的设计。此外,微服务架构也引入了一些挑战,如服务发现、负载均衡、错误处理等,需要合适的工具和框架来支持。

领域事件驱动架构(Domain Event-Driven Architecture)

概念

领域事件驱动架构(Domain Event-Driven Architecture)是一种架构模式,它基于领域事件的概念,将领域模型中的事件作为系统中的核心驱动力。领域事件表示领域中发生的重要事实或状态变化,它们被捕获并在系统中传播,以影响其他部分的行为和状态。在领域事件驱动架构中,系统中的各个模块(或领域服务)都可以订阅感兴趣的领域事件,并根据事件进行相应的处理。这样做的好处是,模块之间的耦合度降低,各模块之间可以更灵活地协同工作,同时也能更好地支持系统的扩展和演进。

示例代码

// 领域事件
public class OrderCreatedEvent {
    private String orderId;
    private String customerId;
    private BigDecimal amount;

    // 构造函数、属性和方法等
}

// 领域服务
public class OrderService {
    private EventPublisher eventPublisher;

    public OrderService(EventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void createOrder(String customerId, List products) {
        // 创建订单的业务逻辑
        Order order = new Order(customerId, products);
        // 订单创建后发布订单创建事件
        OrderCreatedEvent event = new OrderCreatedEvent(order.getId(), order.getCustomerId(), order.getAmount());
        eventPublisher.publish(event);
    }
    
    // 其他订单相关的业务逻辑和操作方法
}

// 订单处理器,订阅订单创建事件并进行相应的处理
public class OrderCreatedEventHandler {
    public void handle(OrderCreatedEvent event) {
        // 处理订单创建事件的业务逻辑
        String orderId = event.getOrderId();
        String customerId = event.getCustomerId();
        BigDecimal amount = event.getAmount();
        // 执行相应的操作,如发送通知、更新报表等
    }
}

// 领域事件发布者接口
public interface EventPublisher {
    void publish(DomainEvent event);
}

// 领域事件发布者的具体实现
public class EventPublisherImpl implements EventPublisher {
    private List handlers;

    public EventPublisherImpl() {
        this.handlers = new ArrayList<>();
    }

    public void registerHandler(EventHandler handler) {
        handlers.add(handler);
    }

    @Override
    public void publish(DomainEvent event) {
        for (EventHandler handler : handlers) {
            if (handler.canHandle(event)) {
                handler.handle(event);
            }
        }
    }
}

// 在应用程序的入口点或配置中,组装和注入事件发布者和事件处理器
public class Application {
    public static void main(String[] args) {
        EventPublisher eventPublisher = new EventPublisherImpl();
        eventPublisher.registerHandler(new OrderCreatedEventHandler());

        OrderService orderService = new OrderService(eventPublisher);

        // 启动应用程序,处理用户请求等
    }
}

在上面的栗子中,定义了一个领域事件OrderCreatedEvent表示订单创建的事件。在OrderService中,当创建订单时,会发布OrderCreatedEventEventPublisher负责将事件传播给对应的事件处理器。OrderCreatedEventHandler是一个事件处理器,它订阅并处理订单创建事件。在EventPublisherImpl中,我们注册了OrderCreatedEventHandler作为事件处理器,并在事件发布时触发相应的处理逻辑。

总结

通过领域事件驱动架构,系统中的各个模块可以根据感兴趣的事件进行订阅和处理,从而实现模块之间的解耦和灵活性。事件的传播机制可以基于同步或异步方式进行,取决于系统的需求和性能要求。

如何选择?

  1. 分层架构:

    • 简要说明:分层架构是一种经典的架构模式,将应用程序按照功能划分为多个层次,通常包括表示层、应用层、领域层和基础设施层。每个层次具有不同的职责和关注点,通过层与层之间的解耦来实现可维护性和可扩展性。
    • 使用场景:适用于小型和中型应用程序,领域模型相对简单,没有明显的复杂性和高性能要求的场景。
  2. 领域驱动设计的六边形架构:

    • 简要说明:六边形架构是一种基于领域驱动设计原则的架构模式,将应用程序划分为三个主要部分:应用服务(Application Services)、领域模型(Domain Model)和基础设施(Infrastructure)。通过六边形架构,可以更好地实现领域模型的解耦、灵活性和可测试性。
    • 使用场景:适用于具有复杂领域模型和高度可扩展性要求的应用程序,强调领域模型的核心性和业务驱动设计。
  3. CQRS:

    • 简要说明:CQRS(Command Query Responsibility Segregation)是一种架构模式,将读操作(查询)和写操作(命令)分离到不同的模块中。通过使用不同的数据模型和处理机制来处理读写操作,可以提高系统的性能、可伸缩性和灵活性。
    • 使用场景:适用于需要高性能读操作和复杂写操作的应用程序,例如具有高并发查询需求或需要实时分析的场景。
  4. 微服务架构:

    • 简要说明:微服务架构将大型应用程序拆分为一组小型、独立的服务,每个服务都运行在自己的进程中,并通过轻量级的通信机制进行通信。每个服务专注于单个业务功能,可以独立开发、部署和扩展。
    • 使用场景:适用于大型和复杂应用程序,需要高度的可扩展性和自治性。适合团队之间的独立开发和部署,以及使用不同技术栈和基础设施的情况。
  5. 领域事件驱动架构:

    • 简要说明:领域事件驱动架构将领域事件作为系统的核心驱动力,通过事件的发布和订阅来实现模块之间的解耦。模块可以订阅感兴趣的事件,并根据事件进行相应的处理。
    • 使用场景:适用于需要实现领域模型的事件驱动、模块之间的松耦合和灵活协同工作的应用程序。特别适合领域模型复杂、演进频繁的领域。

你可能感兴趣的:(DDD领域驱动模型,架构,系统设计,设计规范,系统架构)