在上周六的“AI赋能智能问答系统”课程中，我们深入探讨了如何构建一个现代化、可扩展且高效的智能问答系统。本文将对课程中分享的核心架构进行回顾和总结，重点解析系统从传统三层架构向微服务四层架构的演进，以及其在云原生环境下的部署实践。
在软件架构设计中，我们首先需要思考的是业务、实体、数据和行为应该如何组织和封装。一个合理的架构能够直接反映业务的结构，使得开发人员可以更清晰地理解和迭代业务逻辑。
传统三层架构 vs. 微服务四层架构
课程中，我们对比了两种主流的后端架构模式：
传统三层架构：这是一种大家非常熟悉的模型，由表现层（Controller）、业务逻辑层（Service）和数据访问层（DAO）构成。这种架构的依赖关系是线性的，从上到下依次调用，形成了“贫血模型”。其优点在于结构简单，易于上手，但缺点也十分明显：
业务逻辑分散：核心业务逻辑散落在Service层，与持久化技术强耦合。
灵活性与敏捷性差：随着业务变得复杂，Service层会变得异常臃肿，技术栈的更换或升级会对整体产生巨大影响。
微服务四层架构（DDD思想）：为了应对复杂性，我们引入了领域驱动设计（DDD）的思想，构建了微服务四层架构。该架构的核心理念是“核心关注点分离”和“高内聚、低耦合”。
核心理念：将系统核心的复杂业务逻辑与基础技术实现分离开。
分层：
应用层 (Application Services)：负责协调和指挥，处理请求，但不包含核心业务规则。
领域层 (Domain)：系统的核心，包含了实体（Entities）、聚合（Aggregates）和领域服务（Domain Services）。这里是所有业务逻辑的实现地，与具体技术无关，从而实现了“富模型”。
基础设施层 (Infrastructure)：提供技术支持，如数据库交互、消息队列、缓存等。
优势：
高灵活性：核心业务逻辑独立，技术实现可以灵活替换。
高测试性：领域层是独立的，可以进行单元测试，无需依赖外部组件。
业务逻辑更清晰：聚合了核心业务逻辑，更能应对复杂和长流程的业务场景，如电商核心、金融交易等。
为了让大家更好地理解四层架构，我们以一个“创建订单”的API为例，展示了请求的完整生命周期：
接口层 (Interface Layer)：作为系统的入口，接收外部的HTTP请求。例如，OrderController 接收到一个创建订单的JSON请求，并将其转换为一个PlaceOrderCommand对象。这一层负责协议转换和基本验证。
应用层 (Application Layer)：ApplicationService接收到Command后开始进行业务协调。它会调用UserRepository加载用户聚合根，创建ProductItem值对象，并调用领域对象的核心方法来执行业务操作。值得注意的是，事务（@Transactional）也始于此层。
领域层 (Domain Layer)：这是业务规则的核心。Order.create(...)静态工厂方法被执行，内部会进行如“检查用户账户是否有效”、“校验商品库存”等一系列业务规则验证。如果所有规则都通过，它会创建一个新的Order实例，并发布一个OrderCreatedEvent领域事件，以供其他业务模块解耦监听。
基础设施层 (Infrastructure Layer)：提供所有技术实现。例如，应用层调用orderRepository.save(newOrder)时，实际执行的是OrderRepositoryImpl。这个实现类会将领域对象Order转换为持久化对象OrderPO，并通过JPA或MyBatis等技术将数据保存到数据库中。同样，库存检查等外部依赖的调用也在这一层完成。
通过这个流程，我们可以看到业务逻辑和技术实现被清晰地分开，各层职责单一，极大地提升了系统的可维护性和扩展性。
本次课程通过对比不同的软件架构，结合一个具体的业务案例和现代化的部署方案，为大家展示了如何从零到一构建一个健壮、灵活的AI智能问答系统。希望这些内容能为大家在未来的架构设计和技术选型中提供有益的参考。
Comments (0)