Domain driven design 在设计通用系统时，如何应用领域驱动的设计原则？

所以，假设我们必须设计一个图书馆管理系统。现在，这可以通过领域驱动的设计原则来实现，即编写一种无处不在的语言，然后找出有界的上下文，创建聚合根，最后拥有一个包含书籍、用户、作者等的对象模型

但是，如果我们必须在Salesforce或Sharepoint（具有设计和创建自定义表单和工作流的功能）的线路上设计一个通用系统，该怎么办呢。因此，首先我们将创建一个通用系统，它可以用于实现图书馆管理系统或任何其他系统，如人力资源管理系统或其他系统

在设计通用系统时，我们还能应用领域驱动的设计原则吗？如果是，那么在泛在语言中，我们应该列出域对象，如书籍、用户、作者、员工、部门等，还是只列出通用对象/名称-值对/哈希表。因为，这个通用系统可以用于实现任何其他特定于域的系统

换句话说，如何在创建通用系统时应用领域驱动的设计原则？以后可用于实现其他特定于域的系统

我们还能在设计中应用领域驱动的设计原则吗 通用系统

是的，DDD可以应用于您描述的通用系统

如果是，那么在泛在语言中我们应该列出域对象吗 比如书籍、用户、作者、员工、部门等等，或者我们应该 只需列出通用对象/名称-值对/哈希表

object和hashtable等名称不仅通用，而且具有很强的技术内涵。这种无处不在的语言将在开发人员和领域专家之间共享，因此应该尽可能减少技术影响。这并不是说像object这样的技术名称是错误的-只是要注意域和支持技术基础结构之间的区别。即使所有领域专家都是开发人员，做出这种区分也很重要

可以说，DDD由战术和战略两部分组成。战术模式具有技术性质，包括存储库、价值对象等。这些模式通常对每种语言和平台都有特定的表现形式。这些模式也很可能随着技术的变化而改变。例如，如果与DDD一起使用，战术模式会有所不同。在实现一个通用系统（如您描述的系统）时，战术模式可能会再次不同

---

战略模式在更高的抽象层次上运行，包括有界上下文、上下文映射、无处不在的语言、模型/设计漩涡。这些模式不受技术约束，适用于战术模式之外的情况。从某种意义上说，它们比战术模式更重要，而且无论底层技术如何，它们都适用，因为它们比计算机更适合人们的思维方式。因此，您仍然可以从通用领域的战略模式中获益。

但问题是，如果您正在设计通用系统，您会在通用语言中添加什么。你的目标没有域。总是有一个域，在这种情况下，它只是一个通用/抽象/技术域。你可以在普适语言中使用泛型术语，但它们不必像术语哈希表那样具有技术含义。因此，你的意思是你可以使用PrimaryEntity、ChildEntity或GenericResource之类的词来表示泛型实体。但是，不应该使用Hashtable或Arraylist，因为它们是特定于技术的。是的。使用泛在语言的DDD的目标之一是将领域的核心方面提取为纯知识，尽可能少的技术内涵。这有助于对领域进行推理，也有助于交流。总的来说，这是一个思维上的微妙转变，但它带来了回报。我也有同样的想法，但它仍然让我感到困扰，域用户会根据其所使用的业务为这些对象使用不同的名称/别名。他们会将术语的差异视为技术命名，即使它与逻辑抽象而不是技术术语相关联。这可能会在技术团队和领域团队之间进行讨论时发生。这仍然与普遍存在的语言观念背道而驰。这方面有点自相矛盾。