基于DDD的多租户PaaS平台：核心服务租户定制扩展问询

看起来你在多租户PaaS的DDD实践里遇到了核心服务扩展的典型问题——既要保留核心模块的通用性，又要给特定租户添加定制行为，这确实是DDD落地多租户场景时的常见挑战。结合你的需求，我给你几个贴合DDD原则的解决方案，每个方案都有对应的代码示例参考：

1. 策略模式 + 租户上下文感知 #

这是最贴合DDD“依赖抽象而非具体”原则的方案，把租户定制的可变行为抽象成策略接口，核心服务依赖这个接口，运行时根据当前租户上下文选择对应的策略实现。

实现步骤： #

• 第一步：在核心模块定义定制行为的抽象接口

namespace Core.Services.Strategies
{
    public interface IUserCustomizationStrategy
    {
        void OnUserCreated(User user);
        // 可按需添加更多定制点：如OnUserUpdated、ValidateUser等
    }

    // 核心模块提供默认空实现，避免无定制需求的租户报错
    public class DefaultUserCustomizationStrategy : IUserCustomizationStrategy
    {
        public void OnUserCreated(User user)
        {
            // 默认无操作
        }
    }
}

• 第二步：修改核心UserService，注入策略并在关键节点调用

namespace Core.Services
{
    public class UserService
    {
        private readonly IUserCustomizationStrategy _customizationStrategy;
        private readonly IUserRepository _userRepository; // 假设核心依赖仓储

        // 构造注入策略，默认用空实现
        public UserService(IUserRepository userRepository, 
                          IUserCustomizationStrategy customizationStrategy = null)
        {
            _userRepository = userRepository;
            _customizationStrategy = customizationStrategy ?? new DefaultUserCustomizationStrategy();
        }

        public User CreateUser(UserCreateDto dto)
        {
            // 核心业务逻辑：创建用户的基础规则
            var user = new User(dto.Id, dto.Name, dto.Email);
            _userRepository.Add(user);

            // 调用定制策略的扩展逻辑
            _customizationStrategy.OnUserCreated(user);

            return user;
        }
    }
}

• 第三步：在租户定制项目中实现专属策略

namespace TenantX.Services.Strategies
{
    public class TenantXUserCustomizationStrategy : IUserCustomizationStrategy
    {
        private readonly ITenantXNotificationService _notificationService; // 租户专属服务

        public TenantXUserCustomizationStrategy(ITenantXNotificationService notificationService)
        {
            _notificationService = notificationService;
        }

        public void OnUserCreated(User user)
        {
            // 租户X的定制逻辑：给新用户发送专属欢迎邮件
            _notificationService.SendWelcomeEmail(user.Email);
            // 其他定制操作：如同步用户到租户内部系统
        }
    }
}

• 第四步：在租户项目的组合根（DI容器）中替换策略

// 以ASP.NET Core的Program.cs为例
builder.Services.AddScoped<IUserCustomizationStrategy, TenantXUserCustomizationStrategy>();
// 核心的UserService已注册，仅需替换策略实现即可

2. 装饰器模式（Decorator Pattern） #

如果需要直接修改核心服务方法的执行逻辑（如拦截参数、修改返回值），装饰器模式是绝佳选择——它能在不修改核心服务代码的前提下，给方法添加前置/后置扩展逻辑。

实现步骤： #

• 第一步：给核心UserService定义接口（DDD中建议服务依赖接口）

namespace Core.Services
{
    public interface IUserService
    {
        User CreateUser(UserCreateDto dto);
    }

    public class UserService : IUserService
    {
        // 核心实现保持不变...
    }
}

• 第二步：在租户项目中实现装饰器

namespace TenantX.Services.Decorators
{
    public class TenantXUserServiceDecorator : IUserService
    {
        private readonly IUserService _innerUserService;
        private readonly ITenantXFeatureService _featureService;

        public TenantXUserServiceDecorator(IUserService innerUserService, ITenantXFeatureService featureService)
        {
            _innerUserService = innerUserService;
            _featureService = featureService;
        }

        public User CreateUser(UserCreateDto dto)
        {
            // 前置定制逻辑：租户X要求用户名必须包含前缀
            if (!dto.Name.StartsWith("TX-"))
            {
                dto.Name = $"TX-{dto.Name}";
            }

            // 调用核心服务的原始逻辑
            var user = _innerUserService.CreateUser(dto);

            // 后置定制逻辑：给用户添加租户专属角色
            _featureService.AssignTenantExclusiveRole(user.Id);

            return user;
        }
    }
}

• 第三步：在租户项目的DI容器中注册装饰器，替换原始服务

// ASP.NET Core中注册方式
builder.Services.AddScoped<IUserService, UserService>(); // 先注册核心服务
builder.Services.Decorate<IUserService, TenantXUserServiceDecorator>(); // 用装饰器包裹
// 其他DI容器需手动处理装饰器注册逻辑

3. 领域事件（Domain Events） #

如果你的定制逻辑是附加行为（无需修改核心服务的业务流程或返回值），比如日志、通知、数据同步等，领域事件是最符合DDD思想的方案——核心领域仅负责发布事件，租户定制逻辑通过订阅事件执行。

实现步骤： #

• 第一步：在核心模块定义领域事件

namespace Core.Domain.Events
{
    public record UserCreatedEvent(User User) : IDomainEvent;

    // 通用领域事件标记接口
    public interface IDomainEvent { }
}

• 第二步：修改核心UserService，在关键节点发布事件

namespace Core.Services
{
    public class UserService
    {
        private readonly IUserRepository _userRepository;
        private readonly IDomainEventPublisher _eventPublisher; // 事件发布器接口

        public UserService(IUserRepository userRepository, IDomainEventPublisher eventPublisher)
        {
            _userRepository = userRepository;
            _eventPublisher = eventPublisher;
        }

        public User CreateUser(UserCreateDto dto)
        {
            var user = new User(dto.Id, dto.Name, dto.Email);
            _userRepository.Add(user);

            // 发布领域事件
            _eventPublisher.Publish(new UserCreatedEvent(user));

            return user;
        }
    }
}

• 第三步：在租户项目中实现事件处理器

namespace TenantX.Domain.EventHandlers
{
    public class TenantXUserCreatedEventHandler : IDomainEventHandler<UserCreatedEvent>
    {
        private readonly ITenantXAnalyticsService _analyticsService;

        public TenantXUserCreatedEventHandler(ITenantXAnalyticsService analyticsService)
        {
            _analyticsService = analyticsService;
        }

        public Task Handle(UserCreatedEvent @event)
        {
            // 租户X的定制逻辑：将新用户数据同步到租户分析系统
            return _analyticsService.TrackNewUser(@event.User.Id, @event.User.Email);
        }
    }
}

• 第四步：在租户项目的DI容器中注册事件处理器

builder.Services.AddScoped<IDomainEventHandler<UserCreatedEvent>, TenantXUserCreatedEventHandler>();
// 核心事件发布器会自动发现并调用所有订阅该事件的处理器

额外的DDD实践建议 #

• 保持核心领域纯净：所有租户定制逻辑都应放在租户自己的限界上下文里，不要修改核心模块的领域模型或服务代码，避免核心领域被租户特有逻辑污染。
• 租户上下文的可靠获取：无论是策略模式还是装饰器模式，都需要准确获取当前请求的租户ID/上下文，建议通过中间件、请求上下文或DI注入传递，避免硬编码。
• 优先选择事件驱动：如果定制逻辑是非核心的附加行为，尽量用领域事件，这样核心领域无需感知任何租户的存在，完全符合DDD的“关注点分离”原则。

内容的提问来源于stack exchange，提问作者Alexandre Parshin