AGV/RGV调度系统开发实战：C#领域驱动架构与核心模块解析

1. 从零开始：为什么选择C#和领域驱动设计来构建调度系统？

大家好，我是老张，一个在工业自动化领域摸爬滚打了十多年的老兵。这些年，我经手过不少AGV/RGV调度系统的项目，从早期的“面条式”代码，到后来的分层架构，再到现在的领域驱动设计（DDD），可以说踩过不少坑，也积累了不少实战经验。今天，我想和大家聊聊，为什么在开发这类复杂工业系统时，我会坚定地选择C#和DDD这套组合拳。

首先，AGV/RGV调度系统不是简单的增删改查。它面对的是一个动态、实时、高并发的物理世界。想象一下一个大型电商仓库，几十上百台AGV小车在货架间穿梭，它们要实时接收任务、规划路径、避免碰撞、处理充电、应对急停。这背后是海量的状态变更、事件驱动和业务规则判断。如果用传统的“数据库驱动”开发模式，把业务逻辑都写在Service层甚至控制器里，代码很快就会变成一团乱麻，维护和扩展简直是噩梦。

这时候，领域驱动设计的优势就凸显出来了。DDD的核心思想是让代码结构真实反映业务领域。在调度系统中，核心业务概念非常清晰：**车辆（Vehicle）、任务（TransportTask）、地图（Map）、路径（Route）、工作站（Station）**等等。DDD让我们能够将这些概念建模为一个个富含行为的领域对象（实体、值对象），而不是贫血的数据模型。比如，一辆AGV不应该只是一个包含ID、电量、位置的数据结构，它应该拥有“是否可以执行新任务”、“根据当前位置计算到达某个点的时间”这样的行为。这样做的好处是，业务逻辑被封装在最适合的领域对象内部，高度内聚，变更的影响范围可控，代码的可读性和可维护性大大提升。

那么，为什么是C#呢？在工业控制领域，尤其是国内，上位机开发、数据采集与监控系统（SCADA）很多都是基于Windows平台，.NET生态有着深厚的积累。C#语言本身优雅、强大，配合.NET平台，在实时通信（如Socket、gRPC）、多线程/异步编程、序列化、以及与现代前端（如Vue）通过WebAPI交互方面都非常成熟。用C#来实现DDD的战术模式（实体、聚合根、领域服务、仓储）非常顺手，像async/await语法能让我们优雅地处理大量并发的车辆状态上报和指令下发。

我上一个项目，用这套架构重构了一个老旧的调度系统。重构前，加一个“任务优先级抢占”的需求要改七八个文件，还容易引发隐蔽的bug。重构后，我们只需要在TransportTask聚合根里修改任务状态机，并在TaskDispatchService领域服务中调整调度策略，代码清晰，测试也容易。所以，如果你正在面临一个复杂的、业务逻辑会持续演进的调度系统开发，强烈建议你认真考虑C# + DDD这条技术路线。

2. 领域驱动设计实战：如何划分调度系统的核心领域？

当我们决定采用DDD后，第一个挑战就是如何进行领域划分。划分得好，后续开发顺风顺水；划分得不好，聚合之间纠缠不清，DDD的优势就荡然无存。根据我的经验，一个典型的AGV/RGV调度系统可以划分为以下几个核心子域。

2.1 车辆管理子域

这是系统的“物理”核心。车辆（Vehicle） 是这个子域的聚合根。它不仅仅包含ID、型号、IP地址等属性，更重要的是它的状态（空闲、执行任务中、充电中、故障、离线）和能力（载重、速度、支持的导航方式）。车辆对象内部应该封装状态转换的逻辑，比如从“空闲”到“执行任务中”的转换，需要检查车辆是否健康、电量是否充足。这个子域还负责管理车辆实时上报的位置（Position）、**电量（Battery）**等信息。车辆的位置更新是一个高频事件，我们通常会将其建模为值对象，并通过领域事件（VehiclePositionUpdatedEvent）发布出去，供其他子域（如路径规划）消费。

2.2 任务调度子域

这是系统的“大脑”和“指挥中心”。运输任务（TransportTask） 是这里的聚合根。一个任务包含起点、终点、任务类型（取货、送货、充电）、优先级、创建时间等。任务有自己的生命周期状态，如“待分配”、“已分配”、“执行中”、“已完成”、“已取消”。任务调度的核心算法就封装在这个子域的领域服务——任务调度器（TaskDispatcher） 中。调度器的工作是：从仓储中获取所有“待分配”的任务，结合车辆管理子域提供的车辆实时状态和位置，根据一套策略（如最短距离、最短时间、负载均衡）为任务分配合适的车辆。这个过程会产生一个任务分配（TaskAssignment） 值对象，它记录了任务和车辆的绑定关系。

2.3 路径规划与交通管制子域

这是系统的“导航”和“交警”。当任务被分配后，就需要为车辆规划从A点到B点的最优路径。这个子域的核心是地图（Map） 聚合根，它由节点（Node） 和边（Edge） 组成，构成了一个图数据结构。路径规划器（PathPlanner） 是一个领域服务，它接收起点和终点，利用A*、Dijkstra等算法计算出最优路径（一个节点序列）。更复杂的是交通管制（TrafficControl），它需要实时监控所有在途车辆的计划路径，预测潜在的冲突（如死锁、对向行驶冲突），并执行避碰（CollisionAvoidance） 和解锁（DeadlockResolution） 逻辑。例如，当两辆车预计会在同一个节点相遇时，交通管制服务可能会命令其中一辆车在就近的等待点临时停车。

2.4 地图与基础设施管理子域

这个子域管理静态的、支撑性的数据。除了地图的拓扑结构，它还管理工作站（Station）（如上下料点、充电桩）、区域（Zone）（如高速区、限速区、禁止进入区）、地标（Landmark） 等。这些信息是路径规划和任务执行的基础约束条件。

提示：在划分聚合边界时，一个黄金法则是“通过ID引用，而非持有对象”。例如，TransportTask聚合里只保存分配的VehicleId，而不是整个Vehicle对象。这保证了聚合之间的解耦和独立演化。

通过这样的领域划分，我们的系统架构就清晰了。每个子域可以独立开发、测试和部署。它们之间通过定义清晰的领域事件进行异步通信，比如TaskAssignedEvent（任务已分配）会被车辆控制模块和路径规划模块监听，从而触发后续的车辆指令下发和路径计算。这种松耦合的设计，让系统在面对需求变更时，表现出极强的韧性。

3. 核心模块深度解析：寻路算法与交通管制的C#实现

理论说完了，我们来点硬核的，看看这些核心模块在C#里到底怎么写。我会用我项目里的真实代码片段（当然会做简化）来举例说明。

3.1 寻路算法的实现：不只是A*

很多人一提到寻路就是A*，这没错，但在工业场景下，我们需要考虑更多。我们的地图是一个带权有向图，权重可以是距离、时间或通过难度。

首先，我们定义地图的基础结构：

// 值对象：地图节点
public class MapNode : ValueObject
{
    public string Id { get; private set; }
    public double X { get; private set; }
    public double Y { get; private set; }
    public NodeType Type { get; private set; } // 普通节点、充电桩、上下料点等
    // ... 省略Equals/GetHashCode实现
}

// 值对象：地图