Question

我正在开发一个桌面应用程序，用于处理（以及其他）对机密文档（ MS Word ）的读/写权限。

对于文档，可以定义多个权限。例如：

用户X 可以在 start_date 和 end_date 之间读取文档 D1
用户Y 可以随时读取和编辑文档 D1

此外，文档的权限集应该是可检索的，以便在用户界面上显示。

此外，文档可以由应用程序的当前用户（文档的作者）签名（带证书）。

最近（在有一些无行为的域对象和一些业务/应用程序服务之后），我想出了以下内容：

interface IConfidentialDocument {
    void AddPermission(Permissions permission);
    BunchOfPermissions Permissions { get; } // all defined permissions
    void Sign(User currentUser);
    ... other operations (like ShareToUsers, SendViaEmail)
    string Path { get; }
}

class Permission {
    User User { get; private set; }
    PermissionType Type { get; private set; } // Read, Write, Full etc.
    ... other members (for time bounds etc.)
}

问题是 IConfidentialDocument 必须使用Word Interop库来实现。我无法想出一个很好的方法来包装 Word Interop 功能并在更简单的模型下隐藏其损坏的设计，如上所示。

我正在考虑将 IConfidentialDocument 实现为 WordDocument ，将工作委托给 Microsoft.Office.Interop.Word.Document 。后者将在 WordDocument 的构造函数中传递。这个将由 ConfidentialDocumentFactory.Create（字符串路径）创建。具体工厂将依赖于 Microsoft.Office.Interop.Word.Application 等等......

有没有DDD友好的方式来处理这样的域名？
（如何）在 Word Interop 上定义反腐败层？
我是否应该让这个领域贫血并定义像 DocumentsSigningService ， PermissionsApplyingService 这样的服务？ - 实际上，这就是我现在拥有的 - 它有效，但是......
我应该使用双重发送吗？
- document.SignVia（signingService）
- document.ApplyPermissionsVia（permissionsService，bunchOfPermissions）

业务实际上稍微复杂一些。它还涉及将文档发送给他们允许的用户（通过电子邮件）等。到目前为止我所做的是依靠一组业务服务和应用程序服务来执行大部分逻辑 - ConfidentialDocument 因此没有行为。但是，正如我所说，我正在寻找更好的设计。

欢迎任何想法：）

谢谢！

一些参考（添加链接的声誉不足）：

如何不在实体中注入服务（thinkbeforecoding）
更好的域名事件模式（lostechies）

Answer 1

问题太笼统了，我不明白为什么WordDocument：IConfidentialDocument是坏的。它可以在单独的模块中分配，并被视为适配器。

好的，我会尝试表达自己的想法。

关于DDD，您应该尽可能清楚自己的模型。

MS Word使用自己的模型，其中包含用户，权限和文档等概念。因此，有必要在您的实体和MS提供的实体之间进行模型转换。有一些兴趣点应该考虑。

模型翻译

您的模型和MS Word模型之间存在什么关系？例如，如果有人直接修改了MS Word的权限（绕过您的应用），您的应用是否可以对此更改做出正确的反应？反之亦然。所以，首先我会确定模型之间的关系并推断一些限制。
您的应用是否支持任何其他文档类型/供应商（OpenOffice）？您可以根据具体文档供应商分析详细信息，并将其与您自己的模型分开。

文件模型

创建应用文档对象时，是否始终在内存中加载“真实文档”？我考虑，不。因此，代理很合适。
是否有一些基本的文档字段或状态对于所有文档都是通用的，无论物理文档类型如何？如果是，则基本抽象类“PhysicalDocumentState”作为文档对象的字段将适合该商品。

我建议这样的事情：

Model

我使用像“服务”，“状态”，“门面”这样的词来引用相应的模式。

可能您不需要实现WordDocument，WordPermission，但是：

它可以是有用的，因为它使WordFacadeService更简单
它使MSOfficeInterop完全隔离WordState，并首先关注域操作
创建文档类型时，WordState由WordFacadeService初始化，因此可以实现不同的文档初始化逻辑（例如延迟加载）

现在唯一的问题是确定WordFacadeService简单透明的界面以及分离WordState和WordFacadeService之间的限制控制职责。

最后，我不知道为什么你应该在描述的情况下使用贫血领域模型。

如果有帮助我会很高兴。

如何设计与机密文档管理相关的域模型？

1 个答案:

模型翻译

文件模型