SOA、TDD、DI 和DDD - 一个骗局游戏？

Question

好吧，我将尝试简短、直入主题。我正在尝试开发一个松散耦合的多层服务应用程序，该应用程序可测试并支持依赖项注入。这就是我所拥有的：

在服务层，我有一个 StartSession 方法，它接受启动会话所需的一些关键数据。我的服务类是一个外观，并委托给注入到服务类构造函数中的 ISessionManager 接口的实例。

我在数据访问层中使用存储库模式。因此，我有一个 ISessionRepository，我的域对象将使用它，并且我使用当前的数据访问技术来实现它。 ISessionRepository 具有 GetById、Add 和 Update 方法。

由于我的服务类只是一个外观，因此我认为可以肯定地说我的 ISessionManager 实现是我的体系结构中的实际服务类。此类协调与我的会话域/业务对象的操作。这就是 shell 游戏和问题出现的地方。

在我的 SessionManager 类（具体的 ISessionManager）中，这是我如何实现 StartSession 的：

public ISession StartSession(object sessionStartInfo)
{
    var session = Session.GetSession(sessionStartInfo);

    if (session == null)
        session = Session.NewSession(sessionStartInfo);

    return session;
}

这段代码存在三个问题：

• 首先，显然我可以将此逻辑移至我的 StartSession 方法中。 Session 类，但我认为这会破坏 SessionManager 类的目的，而 SessionManager 类只是成为第二个外观（或者它仍然被视为协调器？）。唉，这就是骗局。
   
• 其次，SessionManager 对 Session 类具有紧密耦合的依赖性。我考虑创建一个可以注入到 SessionManager 中的 ISessionFactory/SessionFactory，但随后我会在工厂内部具有相同的紧密耦合。但是，也许这样可以吗？
   
• 最后，在我看来，真正的 DI 和工厂方法不能混合。毕竟，我们希望避免“new”对象的实例并让容器将实例返回给我们。而真正的 DI 表示我们不应该直接引用容器。那么，如何将具体的 ISessionRepository 类注入到我的 Session 域对象中呢？我是否将其注入到工厂类中，然后在构造新实例（使用“new”）时手动将其传递到 Session 中？
   

请记住，这也只是一项操作，我还需要执行其他任务，例如保存会话、根据各种条件列出会话以及使用解决方案中的其他域对象。另外，Session 对象还封装了授权、验证等业务逻辑。所以（我认为）它需要存在。

我希望实现的目标的关键不仅是功能性的，而且是可测试的。我使用 DI 来打破依赖关系，这样我们就可以使用模拟轻松实现单元测试，并且使我们能够更改具体实现，而无需在多个区域进行更改。

您能否帮助我了解此类设计的最佳实践以及如何最好地实现可靠的 SOA、DDD 和 TDD 解决方案的目标？

更新

我被要求提供一些额外的代码，尽可能简洁：

[ServiceContract()]
public class SessionService : ISessionService
{
    public SessionService(ISessionManager manager) { Manager = manager; }

    public ISessionManager Manager { get; private set; }

    [OperationContract()]
    public SessionContract StartSession(SessionCriteriaContract criteria)
    {
        var session = Manager.StartSession(Mapper.Map<SessionCriteria>(criteria));

        return Mapper.Map<SessionContract>(session);
    }
}

public class SessionManager : ISessionManager
{
    public SessionManager() { }

    public ISession StartSession(SessionCriteria criteria)
    {
        var session = Session.GetSession(criteria);

        if (session == null)
            session = Session.NewSession(criteria);

        return session;
    }
}

public class Session : ISession
{
    public Session(ISessionRepository repository, IValidator<ISession> validator)
    {
        Repository = repository;
        Validator = validator;
    }

    // ISession Properties

    public static ISession GetSession(SessionCriteria criteria)
    {
        return Repository.FindOne(criteria);
    }

    public static ISession NewSession(SessionCriteria criteria)
    {
        var session = ????;

        // Set properties based on criteria object

        return session;
    }

    public Boolean Save()
    {
        if (!Validator.IsValid(this))
            return false;

        return Repository.Save(this);
    }
}

而且，显然，有一个 ISessionRepository 接口和具体的 XyzSessionRepository 类，我认为不需要显示。

第二次更新

我将 IValidator 依赖项添加到会话域对象中，以说明还有其他组件正在使用。

Answer 1

发布的代码澄清了很多。在我看来，会话类保存状态（具有行为），而服务和管理器类严格执行操作/行为。

您可能会考虑从会话中删除存储库依赖项并将其添加到会话管理器中。因此，您的 Manager 类将具有一个 Save(ISession session) 方法，然后调用 Repository.Save(session)，而不是 Session 调用 Repository.Save(this)。这意味着会话本身不需要由容器管理，并且通过“new Session()”（或使用执行相同操作的工厂）创建它是完全合理的。我认为 Session 上的 Get- 和 New- 方法是静态的这一事实是它们可能不属于该类的线索/气味（此代码是否可以编译？似乎您正在静态方法中使用实例属性）。

最后，在我看来，真正的 DI
和工厂方法不能混合。后
所有，我们希望避免“new”
对象的实例并让
容器将实例返回给我们。
真正的 DI 说我们不应该
直接引用容器。所以，
那我怎么得到具体的
ISessionRepository类注入
我的会话域对象？我有吗
然后注入工厂类
手动将其传递到 Session 时
构造一个新实例（使用
“新”）？

当涉及到通过 IOC 容器管理混合状态和服务的类时，这个问题经常被问到。一旦您使用了使用“new”的抽象工厂，您就会失去对象图中从该类向下的 DI 框架的好处。您可以通过完全分离状态和服务并仅让提供由容器管理的服务/行为的类来摆脱这种情况。这导致通过方法调用（也称为函数式编程）传递所有数据。一些容器（温莎就是其中之一）也为这个问题提供了解决方案（在温莎它被称为工厂设施）。

编辑：想补充一点，函数式编程也会导致福勒所说的“贫血领域模型”。这在 DDD 中通常被认为是一件坏事，因此您可能必须根据我上面发布的建议来权衡这一点。

Answer 2

只是一些评论...

毕竟，我们希望避免“new”对象的实例并让容器将实例返回给我们。

这并不是 100% 正确的。您希望避免仅跨所谓的“接缝”进行“new”操作，这些接缝基本上是层之间的线。如果您尝试使用存储库抽象持久性 - 这就是一个接缝，如果您尝试将域模型与 UI（经典模型 - system.web 参考）分离，那么就有一个接缝。如果您位于同一层，那么将一个实现与另一个实现解耦有时没有什么意义，只会增加额外的复杂性（无用的抽象、ioc 容器配置等）。您想要抽象某些东西的另一个（明显的）原因是您现在已经需要多态性。

真正的 DI 表示我们不应该直接引用容器。

这是真实的。但您可能缺少的另一个概念是所谓的组合根（事物有一个名字是件好事:)。这个概念解决了与“何时使用服务定位器”的混淆。想法很简单 - 你应该尽快构建你的依赖图。应该只有 1 个地方是您实际引用 ioc 容器的地方。

例如，在asp.net mvc应用程序中，组合的共同点是ControllerFactory。

我是否将其注入到工厂类中，然后在构造新实例时手动将其传递到会话中

正如我所见，工厂通常有两件事：

1.创建复杂对象（构建器模式有很大帮助）
2.解决违反开放封闭和单一职责原则

public void PurchaseProduct(Product product){
  if(product.HasSomething) order.Apply(new FirstDiscountPolicy());
  if(product.HasSomethingElse) order.Apply(new SecondDiscountPolicy());
}

变为：

public void PurchaseProduct(Product product){
  order.Apply(DiscountPolicyFactory.Create(product));
}

这样，如果满足以下条件，则无需修改包含 PurchaseProduct 的类 ：新的折扣政策即将出现，PurchaseProduct 将只负责购买产品，而不知道要应用什么折扣。

PS 如果您对 DI 感兴趣，您应该阅读 马克·西曼。

Answer 3

我想我应该发布我最终遵循的方法，同时给予上面应有的认可。

在阅读了一些有关 DDD 的其他文章后，我终于发现我们的域对象不应该对其创建或持久性负责，并且可以从域内“新建”域对象的实例。层（正如阿尼斯所回避的那样）。

因此，我保留了 SessionManager 类，但将其重命名为 SessionService，这样可以更清楚地看出它是一个域服务（不要与门面层中的 SessionService 混淆）。它现在的实现如下：

public class SessionService : ISessionService
{
    public SessionService(ISessionFactory factory, ISessionRepository repository)
    {
        Factory = factory;
        Repository = repository;
    }

    public ISessionFactory Factory { get; private set; }
    public ISessionRepository Repository { get; private set; }

    public ISession StartSession(SessionCriteria criteria)
    {
        var session = Repository.GetSession(criteria);

        if (session == null)
            session = Factory.CreateSession(criteria);
        else if (!session.CanResume)
            thrown new InvalidOperationException("Cannot resume the session.");

        return session;
    }
}

Session 类现在更像是一个真正的域对象，只关心使用 Session 时所需的状态和逻辑，例如上面显示的 CanResume 属性和验证逻辑。

SessionFactory 类负责创建新实例，并允许我仍然注入容器提供的 ISessionValidator 实例，而无需直接引用容器本身：

public class SessionFactory : ISessionFactory
{
    public SessionFactory(ISessionValidator validator)
    {
        Validator = validator;
    }

    public ISessionValidator Validator { get; private set; }

    public Session CreateSession(SessionCriteria criteria)
    {
        var session = new Session(Validator);

        // Map properties

        return session;
    }
}

除非有人指出我的方法中的缺陷，否则我很满意这与DDD 并为我提供了对单元测试等的全面支持 - 我所追求的一切。