[企业级制造系统]：实现多厂区协同的DDD架构实战指南

2026-04-30 11:29:42作者：羿妍玫Ivan

在当今制造业数字化转型浪潮中，企业面临着多厂区数据隔离、系统扩展性不足、业务逻辑与技术实现紧耦合等痛点。TMom作为一款支持多厂区/多项目级的MOM/MES系统，基于.NET8、SqlSugar和DDD(领域驱动设计)架构，提供了一套完整的分布式架构解决方案，有效解决了数据一致性和性能优化难题。本文将深入剖析TMom如何通过创新架构设计满足复杂制造场景需求，为企业级应用开发提供实战参考。

核心特性：如何通过技术选型突破制造系统瓶颈？

制造企业在系统建设过程中，常常面临技术选型的困境：既要满足高性能、高可用的要求，又要兼顾开发效率和学习成本。TMom的技术栈选择背后蕴含着怎样的考量？让我们从三个关键技术点展开分析。

如何通过.NET8提升制造系统的并发处理能力？

制造业生产数据具有实时性强、并发量大的特点，传统框架往往难以应对高峰期的请求压力。TMom选择.NET8作为核心框架，正是看中了其在性能优化方面的显著优势。

问题：某汽车零部件厂在生产高峰期，MES系统频繁出现响应延迟，尤其在工单下达和工艺数据采集环节，平均响应时间超过3秒，严重影响生产效率。

方案：.NET8引入的分层编译和自适应优化技术，能够根据运行时数据动态调整代码优化策略。在TMom中，通过以下配置实现性能提升：

// Program.cs中启用.NET8性能优化特性
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers(options =>
{
    options.Filters.Add<PerformanceMonitorFilter>(); // 性能监控过滤器
});
// 配置Kestrel服务器以支持更高并发
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxConcurrentConnections = 10000;
    serverOptions.Limits.MaxConcurrentUpgradedConnections = 1000;
});

效果：系统在每秒500并发请求下，响应时间从3秒降至200ms，提升1500%，且CPU利用率降低40%。同时，.NET8的跨平台特性使系统能够部署在Linux服务器上，硬件成本降低30%。

企业级实践注意事项：

生产环境建议开启.NET8的ReadyToRun编译，牺牲部分启动时间换取运行时性能提升
针对制造系统的批处理任务，使用.NET8的Parallel.ForEachAsync替代传统线程池，避免线程阻塞
结合Application Insights监控关键业务接口性能，设置阈值告警

SqlSugar ORM如何平衡开发效率与查询性能？

数据访问层是制造系统的核心，既要满足复杂的业务查询需求，又要保证数据库操作的高效性。TMom选择SqlSugar作为ORM框架，在众多ORM中脱颖而出。

问题：某电子制造企业的生产报表系统，涉及多表关联查询和复杂统计计算，使用Entity Framework Core时，复杂查询平均耗时2.5秒，且SQL优化困难。

方案：SqlSugar提供了灵活的查询语法和强大的SQL生成能力，同时支持原生SQL混合编程。以下是TMom中一个复杂工艺路线查询的实现：

// 工艺路线查询优化示例
public async Task<ProcessRouteDto> GetProcessRouteDetail(long routeId)
{
    // 使用SqlSugar的链式查询+原生SQL混合方式
    return await _db.Queryable<ProcessRoute>()
        .LeftJoin<ProcessOperation>((r, o) => r.Id == o.RouteId)
        .LeftJoin<ProcessRouteSequence>((r, o, s) => o.Id == s.OperationId)
        .Where(r => r.Id == routeId)
        .Select((r, o, s) => new ProcessRouteDto
        {
            RouteId = r.Id,
            RouteName = r.Name,
            Operations = SqlFunc.Subqueryable<ProcessOperation>()
                .Where(op => op.RouteId == r.Id)
                .Select(op => new OperationDto
                {
                    OperationId = op.Id,
                    OperationName = op.Name,
                    Sequence = SqlFunc.Subqueryable<ProcessRouteSequence>()
                                .Where(seq => seq.OperationId == op.Id)
                                .Select(seq => seq.Sequence)
                                .First()
                }).ToList()
        })
        .WithCache(300) // 缓存5分钟
        .FirstAsync();
}

效果：通过SqlSugar的查询优化和缓存机制，相同的复杂查询耗时从2.5秒降至300ms，性能提升800%。同时，开发效率比使用Dapper提高40%，代码量减少30%。

技术对比：

特性	SqlSugar	Entity Framework Core	Dapper
查询性能	★★★★★	★★★☆☆	★★★★☆
开发效率	★★★★☆	★★★★★	★★☆☆☆
学习曲线	低	中	中
复杂查询支持	强	中	依赖手写SQL
多数据库支持	多数据库无缝切换	需额外适配	需手写不同SQL

企业级实践注意事项：

针对制造系统中的大批量数据导入，使用SqlSugar的BulkCopy功能，比普通Insert快10倍以上
复杂报表查询建议使用View+存储过程结合的方式，通过SqlSugar调用
开启SqlSugar的SQL日志功能，监控慢查询并优化

DDD架构如何解决制造系统的业务复杂性？

制造系统涉及生产计划、工艺管理、质量控制等多个业务领域，传统的三层架构难以应对业务的快速变化。DDD(领域驱动设计)通过将业务逻辑与技术实现分离，为复杂系统提供了清晰的设计思路。

问题：某重工企业的MES系统在扩展新厂区时，发现原有的代码结构难以复用，各模块之间耦合严重，新功能开发周期长达2个月。

方案：TMom采用DDD架构，将系统分为领域层、应用层、基础设施层和表现层。以工单管理为例，领域模型设计如下：

// 领域实体
public class WorkOrder : RootEntity<long>
{
    public string OrderNo { get; private set; }
    public long ProductId { get; private set; }
    public int Quantity { get; private set; }
    public WorkOrderStatus Status { get; private set; }
    public DateTime PlanStartTime { get; private set; }
    public DateTime PlanEndTime { get; private set; }
    
    // 领域行为
    public void UpdateStatus(WorkOrderStatus newStatus)
    {
        // 状态转换业务规则
        if (!IsValidStatusTransition(Status, newStatus))
        {
            throw new DomainException($"工单状态从{Status}到{newStatus}的转换不允许");
        }
        Status = newStatus;
        AddDomainEvent(new WorkOrderStatusChangedEvent(this));
    }
    
    private bool IsValidStatusTransition(WorkOrderStatus current, WorkOrderStatus target)
    {
        // 实现状态转换规则
        return true;
    }
}

// 领域服务
public class WorkOrderDomainService
{
    private readonly IWorkOrderRepository _workOrderRepository;
    private readonly IProductionLineRepository _lineRepository;
    
    public WorkOrderDomainService(IWorkOrderRepository workOrderRepository, 
                                 IProductionLineRepository lineRepository)
    {
        _workOrderRepository = workOrderRepository;
        _lineRepository = lineRepository;
    }
    
    public async Task AssignWorkOrderToLine(long orderId, long lineId)
    {
        var order = await _workOrderRepository.GetByIdAsync(orderId);
        var line = await _lineRepository.GetByIdAsync(lineId);
        
        if (order == null || line == null)
        {
            throw new DomainException("工单或产线不存在");
        }
        
        if (!line.CanAcceptOrder(order))
        {
            throw new DomainException($"产线{line.Name}无法接受此工单");
        }
        
        order.AssignToLine(lineId);
        await _workOrderRepository.UpdateAsync(order);
    }
}

效果：采用DDD架构后，新厂区功能扩展周期从2个月缩短至2周，代码复用率提升60%，系统维护成本降低40%。

企业级实践注意事项：

不要过度设计领域模型，核心业务才需要严格的DDD设计
聚合根的划分要适度，避免过大或过小
领域事件的使用要谨慎，过多的事件会增加系统复杂度

实现原理：分布式制造系统的架构创新点

多厂区制造系统面临着数据隔离、事务一致性、性能优化等诸多挑战。TMom通过创新的架构设计，为这些问题提供了切实可行的解决方案。让我们深入探讨其实现原理。

如何通过动态数据源实现多厂区数据隔离？

多厂区部署时，数据隔离是首要解决的问题。如何在保证数据安全隔离的同时，又能实现跨厂区的数据聚合分析？

问题：某跨国制造企业在中国、东南亚设有多个生产基地，各基地数据需独立存储，但集团总部需要实时查看各基地的生产数据。

方案：TMom设计了基于SqlSugar的动态数据源切换机制，结合仓储模式实现多租户数据隔离：

// 动态数据源配置
public class DynamicDbContext
{
    private readonly ISqlSugarClient _sqlSugarClient;
    private readonly IHttpContextAccessor _httpContextAccessor;
    
    public DynamicDbContext(ISqlSugarClient sqlSugarClient, 
                           IHttpContextAccessor httpContextAccessor)
    {
        _sqlSugarClient = sqlSugarClient;
        _httpContextAccessor = httpContextAccessor;
    }
    
    public ISqlSugarClient GetDbClient()
    {
        var tenantId = _httpContextAccessor.HttpContext?.Items["TenantId"]?.ToString();
        if (string.IsNullOrEmpty(tenantId))
        {
            throw new Exception("租户ID不存在");
        }
        
        // 根据租户ID切换数据源
        _sqlSugarClient.ChangeDatabase(tenantId);
        return _sqlSugarClient;
    }
}

// 仓储实现
public class WorkOrderRepository : BaseRepository<WorkOrder>, IWorkOrderRepository
{
    private readonly DynamicDbContext _dynamicDbContext;
    
    public WorkOrderRepository(DynamicDbContext dynamicDbContext)
    {
        _dynamicDbContext = dynamicDbContext;
    }
    
    protected override ISqlSugarClient Db => _dynamicDbContext.GetDbClient();
    
    // 实现具体方法...
}

效果：系统成功支持10个厂区的独立部署，数据隔离级别达到数据库级，同时跨厂区报表查询性能保持在1秒以内。

stateDiagram-v2 [] --> 未选择厂区未选择厂区 --> 选择厂区: 用户登录选择厂区 --> 切换数据源: 验证权限切换数据源 --> 数据操作: 执行查询/更新数据操作 --> []: 操作完成选择厂区 --> [*]: 退出登录

企业级实践注意事项：

多租户数据源切换必须在权限验证之后进行
跨租户查询需特别处理，避免数据泄露
动态数据源切换建议配合AOP实现，减少重复代码

如何通过事件驱动架构保证生产数据一致性？

制造系统中，工单状态变更、物料消耗、质量检验等业务操作需要保证数据一致性，传统的事务管理方式难以应对分布式场景。

问题：某汽车制造厂的生产执行系统中，工单完成时需要同步更新库存、质量记录和生产报表，传统的事务方式经常因网络问题导致部分更新失败，数据不一致。

方案：TMom采用事件驱动架构，通过领域事件和消息队列实现分布式事务：

// 领域事件定义
public class WorkOrderCompletedEvent : IntegrationEvent
{
    public long OrderId { get; set; }
    public string OrderNo { get; set; }
    public DateTime CompletedTime { get; set; }
    public List<MaterialConsumption> Materials { get; set; }
}

// 事件发布
public class WorkOrderService : IWorkOrderService
{
    private readonly IWorkOrderRepository _repository;
    private readonly IEventBus _eventBus;
    
    public WorkOrderService(IWorkOrderRepository repository, IEventBus eventBus)
    {
        _repository = repository;
        _eventBus = eventBus;
    }
    
    public async Task CompleteOrder(long orderId)
    {
        var order = await _repository.GetByIdAsync(orderId);
        order.Complete();
        await _repository.UpdateAsync(order);
        
        // 发布事件
        await _eventBus.PublishAsync(new WorkOrderCompletedEvent
        {
            OrderId = order.Id,
            OrderNo = order.OrderNo,
            CompletedTime = DateTime.Now,
            Materials = order.MaterialConsumptions
        });
    }
}

// 事件处理 - 库存更新
public class WorkOrderCompletedInventoryHandler : IIntegrationEventHandler<WorkOrderCompletedEvent>
{
    private readonly IInventoryRepository _inventoryRepository;
    
    public WorkOrderCompletedInventoryHandler(IInventoryRepository inventoryRepository)
    {
        _inventoryRepository = inventoryRepository;
    }
    
    public async Task Handle(WorkOrderCompletedEvent @event)
    {
        foreach (var material in @event.Materials)
        {
            await _inventoryRepository.ReduceStock(material.MaterialId, material.Quantity);
        }
    }
}

// 事件处理 - 质量记录
public class WorkOrderCompletedQualityHandler : IIntegrationEventHandler<WorkOrderCompletedEvent>
{
    private readonly IQualityRecordRepository _qualityRepository;
    
    // 实现质量记录逻辑...
}

效果：通过事件驱动架构，系统数据一致性达到99.99%，因数据不一致导致的生产异常减少80%。同时，系统模块间耦合度降低，新功能开发速度提升50%。

**sequenceDiagram participant 工单服务 participant 事件总线 participant 库存服务 participant 质量服务 participant 报表服务

工单服务->>工单服务: 完成工单(领域逻辑)
工单服务->>事件总线: 发布工单完成事件
事件总线->>库存服务: 处理库存更新
事件总线->>质量服务: 处理质量记录
事件总线->>报表服务: 更新生产报表
库存服务-->>事件总线: 完成库存更新
质量服务-->>事件总线: 完成质量记录
报表服务-->>事件总线: 完成报表更新**企业级实践注意事项**：

关键业务事件需实现重试机制，确保最终一致性
事件处理顺序可能影响业务结果，需设计合理的事件排序机制
事件数据应包含足够信息，避免处理时再次查询数据库

如何通过多级缓存优化制造系统性能？

制造系统的实时数据查询和统计分析对性能要求极高，如何在高并发场景下保持系统响应速度？

问题：某3C制造企业的生产监控大屏需要实时展示各产线的生产数据，高峰期每秒有数百次查询请求，数据库压力巨大，查询延迟严重。

方案：TMom设计了多级缓存策略，结合内存缓存和Redis缓存，大幅提升查询性能：

// 缓存AOP实现
public class CacheAOP : IInterceptor
{
    private readonly IRedisRepository _redisRepository;
    private readonly IMemoryCache _memoryCache;
    
    public CacheAOP(IRedisRepository redisRepository, IMemoryCache memoryCache)
    {
        _redisRepository = redisRepository;
        _memoryCache = memoryCache;
    }
    
    public async Task InterceptAsync(IInvocation invocation)
    {
        var cacheAttribute = invocation.Method.GetCustomAttribute<CacheAttribute>();
        if (cacheAttribute == null)
        {
            await invocation.ProceedAsync();
            return;
        }
        
        // 生成缓存键
        var cacheKey = GenerateCacheKey(invocation);
        
        // 1. 先查内存缓存
        var result = _memoryCache.Get(cacheKey);
        if (result != null)
        {
            invocation.ReturnValue = result;
            return;
        }
        
        // 2. 再查Redis缓存
        result = await _redisRepository.GetAsync(cacheKey);
        if (result != null)
        {
            _memoryCache.Set(cacheKey, result, TimeSpan.FromMinutes(5));
            invocation.ReturnValue = result;
            return;
        }
        
        // 3. 查询数据库
        await invocation.ProceedAsync();
        result = invocation.ReturnValue;
        
        // 4. 设置缓存
        await _redisRepository.SetAsync(cacheKey, result, cacheAttribute.Expiration);
        _memoryCache.Set(cacheKey, result, TimeSpan.FromMinutes(5));
    }
    
    private string GenerateCacheKey(IInvocation invocation)
    {
        // 生成唯一缓存键...
    }
}

// 应用缓存
[ServiceAspect]
public class ProductionMonitorService : IProductionMonitorService
{
    private readonly IWorkOrderRepository _workOrderRepository;
    
    public ProductionMonitorService(IWorkOrderRepository workOrderRepository)
    {
        _workOrderRepository = workOrderRepository;
    }
    
    [Cache(Expiration = 60)] // 缓存60秒
    public async Task<ProductionDataDto> GetLineProductionData(long lineId)
    {
        // 复杂查询逻辑...
    }
}

效果：通过多级缓存策略，生产监控大屏的查询响应时间从500ms降至30ms，性能提升1567%，数据库负载降低80%。

图：TMom系统中的生产监控大屏，通过多级缓存实现实时数据展示

企业级实践注意事项：

缓存键设计需包含租户信息，避免多租户场景下的缓存污染
缓存过期时间设置需根据数据更新频率调整，生产数据建议设置较短的过期时间
实现缓存预热机制，避免系统启动后大量缓存穿透

架构设计中的反模式规避

在制造系统架构设计中，一些常见的反模式会导致系统扩展性差、性能瓶颈等问题。TMom在设计过程中特别注意规避这些问题。

问题：许多制造系统随着业务发展，逐渐出现"大泥球"架构，模块边界模糊，代码难以维护。

方案：TMom通过以下措施规避架构反模式：

严格的模块边界：通过领域边界划分模块，模块间通过明确定义的接口通信

// 模块间接口定义
public interface IWorkOrderService
{
    Task<WorkOrderDto> GetByIdAsync(long id);
    Task CreateAsync(CreateWorkOrderDto dto);
    Task UpdateStatusAsync(long id, WorkOrderStatus status);
}

// 模块实现
[ServiceAspect]
public class WorkOrderService : IWorkOrderService
{
    // 实现接口方法...
}

// 其他模块调用
public class ProductionScheduleService
{
    private readonly IWorkOrderService _workOrderService;
    
    public ProductionScheduleService(IWorkOrderService workOrderService)
    {
        _workOrderService = workOrderService; // 通过接口依赖，而非具体实现
    }
    
    // 使用接口方法...
}

避免贫血领域模型：将业务逻辑封装在领域对象中，而非仅作为数据载体
控制事务边界：避免长事务和分布式事务，通过最终一致性保证数据完整性
合理的服务粒度：避免"上帝服务"，每个服务专注于单一职责

架构反模式警示：在制造系统中，最常见的架构反模式是"事务脚本"模式，即将所有业务逻辑放在服务层的方法中，导致业务规则分散、难以维护。TMom通过DDD的领域模型设计，将业务规则封装在领域对象中，有效避免了这一问题。

应用场景：企业级制造系统的实战案例

理论架构需要在实际业务场景中落地才能体现价值。TMom在多个制造企业的实践中，针对不同业务场景提供了定制化解决方案。

如何实现多厂区工单协同生产？

业务场景：某大型家电企业拥有3个生产基地，分别生产不同部件，最终在总装厂完成组装。需要实现工单跨厂区协同，确保部件生产与总装进度匹配。

解决方案：TMom设计了基于事件驱动的跨厂区协同机制：

工单分解：总装工单创建后，自动分解为各部件厂的生产工单
进度同步：各部件厂工单状态实时同步至总装厂
异常协调：当某部件生产延迟时，自动触发总装计划调整

// 工单分解领域服务
public class WorkOrderDecompositionService
{
    private readonly IWorkOrderRepository _workOrderRepository;
    private readonly IProductStructureRepository _productStructureRepository;
    private readonly IEventBus _eventBus;
    
    public async Task DecomposeOrder(long assemblyOrderId)
    {
        var assemblyOrder = await _workOrderRepository.GetByIdAsync(assemblyOrderId);
        var productStructure = await _productStructureRepository.GetByProductId(assemblyOrder.ProductId);
        
        foreach (var component in productStructure.Components)
        {
            // 创建部件工单
            var componentOrder = new WorkOrder
            {
                OrderNo = GenerateComponentOrderNo(assemblyOrder.OrderNo, component.Id),
                ProductId = component.ComponentId,
                Quantity = component.Quantity * assemblyOrder.Quantity,
                PlanStartTime = assemblyOrder.PlanStartTime.AddDays(-component.LeadTime),
                PlanEndTime = assemblyOrder.PlanStartTime.AddDays(-1),
                FactoryId = component.FactoryId, // 指定生产厂区
                ParentOrderId = assemblyOrderId
            };
            
            await _workOrderRepository.InsertAsync(componentOrder);
            
            // 发布部件工单创建事件
            await _eventBus.PublishAsync(new ComponentOrderCreatedEvent
            {
                OrderId = componentOrder.Id,
                OrderNo = componentOrder.OrderNo,
                ParentOrderId = assemblyOrderId,
                FactoryId = component.FactoryId
            });
        }
    }
}

实施效果：

跨厂区协同效率提升60%，部件齐套率从85%提升至98%
生产异常响应时间从4小时缩短至30分钟
总装等待时间减少40%，生产效率提升25%

如何实现制造过程的实时质量监控？

业务场景：某汽车零部件企业需要对关键工序的质量数据进行实时监控，当出现质量异常时及时报警并停机，避免批量质量问题。

解决方案：TMom设计了基于实时数据采集和规则引擎的质量监控系统：

数据采集：通过OPC UA协议实时采集设备参数
规则引擎：定义质量监控规则，实时分析数据
异常处理：触发质量异常事件，通知相关人员并控制设备

// 质量监控服务
public class QualityMonitorService
{
    private readonly IQualityRuleRepository _ruleRepository;
    private readonly IEquipmentDataRepository _dataRepository;
    private readonly IEventBus _eventBus;
    
    public async Task MonitorQualityData(EquipmentDataDto data)
    {
        // 获取该设备的质量监控规则
        var rules = await _ruleRepository.GetByEquipmentId(data.EquipmentId);
        
        foreach (var rule in rules)
        {
            // 执行规则检查
            if (RuleEngine.Evaluate(rule.Expression, data))
            {
                // 触发质量异常事件
                await _eventBus.PublishAsync(new QualityAbnormalityEvent
                {
                    EquipmentId = data.EquipmentId,
                    WorkOrderId = data.WorkOrderId,
                    RuleId = rule.Id,
                    Data = data,
                    Timestamp = DateTime.Now
                });
                
                // 记录质量异常
                await _dataRepository.InsertQualityAbnormality(new QualityAbnormality
                {
                    // 异常信息...
                });
            }
        }
    }
}

图：TMom系统中的质量监控界面，实时显示生产过程中的质量数据和异常报警

实施效果：

质量异常发现时间从平均2小时缩短至实时
不良品率降低35%，质量成本减少28%
客户投诉减少50%，产品质量满意度提升40%

技术难点：多厂区数据聚合分析的三种解决方案对比

制造企业总部需要实时掌握各厂区的生产数据，进行汇总分析和决策。多厂区数据聚合面临着数据量大、实时性要求高、跨数据库查询等技术挑战。

问题：某集团企业有5个生产基地，每个基地数据库独立部署，集团总部需要实时查看各基地的生产进度、质量状况和设备利用率等关键指标。

解决方案对比：

方案一：实时跨库查询

实现思路：通过动态数据源切换，在查询时依次访问各厂区数据库，汇总数据。

public async Task<GroupProductionSummaryDto> GetGroupProductionSummary()
{
    var summary = new GroupProductionSummaryDto();
    var factoryIds = await _factoryRepository.GetAllFactoryIds();
    
    foreach (var factoryId in factoryIds)
    {
        // 切换到对应厂区数据源
        _dynamicDbContext.SetTenantId(factoryId);
        
        // 查询该厂区数据
        var factorySummary = await _productionRepository.GetFactoryProductionSummary();
        
        // 汇总数据
        summary.TotalOrders += factorySummary.OrderCount;
        summary.CompletedOrders += factorySummary.CompletedCount;
        // 其他指标汇总...
    }
    
    return summary;
}

优点：实现简单，数据实时性高缺点：查询性能随厂区数量增加线性下降，网络开销大 适用场景：厂区数量少（<5），对实时性要求极高的场景

方案二：数据同步到中心数据库

实现思路：通过ETL工具或CDC(变更数据捕获)技术，将各厂区数据实时同步到中心数据库，查询时只需访问中心数据库。

// 数据同步服务
public class DataSyncService : IHostedService
{
    private readonly IChangeDataCaptureClient _cdcClient;
    private readonly ICentralDbRepository _centralDbRepository;
    
    public async Task StartAsync(CancellationToken cancellationToken)
    {
        // 订阅各厂区数据变更
        _cdcClient.Subscribe("factory1", "work_order", async (change) => 
        {
            await _centralDbRepository.SyncWorkOrderChange(change);
        });
        
        // 其他表订阅...
    }
    
    // 实现接口其他方法...
}

优点：查询性能好，支持复杂分析缺点：数据有延迟，增加了系统复杂度和维护成本 适用场景：厂区数量多，对实时性要求不高（允许几分钟延迟）的场景

方案三：实时计算+时序数据库

实现思路：各厂区实时将关键指标发送到消息队列，通过流处理引擎（如Flink）实时计算汇总指标，存储到时序数据库供查询。

// 指标采集服务
public class MetricsCollectionService
{
    private readonly IEventBus _eventBus;
    
    public async Task CollectProductionMetrics(ProductionDataDto data)
    {
        // 计算关键指标
        var metrics = new ProductionMetrics
        {
            FactoryId = data.FactoryId,
            Timestamp = DateTime.Now,
            Oee = CalculateOee(data),
            ProductionRate = data.CompletedQuantity / data.PlanQuantity,
            // 其他指标...
        };
        
        // 发送到消息队列
        await _eventBus.PublishAsync(new ProductionMetricsEvent(metrics));
    }
}

// Flink作业处理
public class MetricsAggregationJob
{
    public void Configure(StreamExecutionEnvironment env)
    {
        env.AddSource(new KafkaSource<ProductionMetricsEvent>())
           .keyBy(m => m.FactoryId)
           .window(TumblingProcessingTimeWindows.of(Time.seconds(30)))
           .aggregate(new MetricsAggregator())
           .addSink(new InfluxDBSink());
    }
}