所以，假设我们必须设计一个图书馆管理系统。现在，这可以通过领域驱动的设计原则来完成，方法是编写一种通用语言，然后找出有界上下文，创建聚合根，最后拥有一个包含书籍、用户、作者等的对象模型。
但是，如果我们必须在 Salesforce 或 Sharepoint 上设计一个通用系统（具有设计和创建自定义表单和工作流的能力）。因此，首先我们将创建一个通用系统，它可以用于实现图书馆管理系统或任何其他系统，如人力资源管理系统或其他系统。
我们还能在设计通用系统时应用领域驱动设计原则吗？如果是，那么在普遍存在的语言中，我们应该列出领域对象，如书籍、用户、作者、员工、部门等，还是应该只列出通用对象/名称值对/哈希表。因为，这个通用系统可用于实现任何其他特定领域的系统。
换句话说，如何在创建通用系统时应用领域驱动设计原则？稍后可用于实现其他特定领域的系统。
我们还能在设计通用系统时应用领域驱动设计原则吗？
是的，DDD 可以应用于您描述的通用系统。
如果是，那么在普遍存在的语言中，我们应该列出领域对象，如书籍、用户、作者、员工、部门等，还是应该只列出通用对象/名称值对/哈希表。
像object、hashtable这样的名字不仅通用，而且具有很强的技术内涵。普遍存在的语言将在开发人员和领域专家之间共享，因此应尽可能减少技术影响。这并不是说像object这样的技术名称是错误的名称 - 请注意您的域和支持技术基础设施之间的区别。即使所有领域专家都是开发人员，做出这种区分也很重要。
可以说，DDD 由两个部分组成——战术和战略。战术模式具有技术性质，包括存储库、值对象等。这些模式通常对每种语言和平台都有特定的表现形式。随着技术的变化，这些模式也最有可能发生变化。例如，如果在 DDD 中使用事件溯源，则战术模式会有所不同。在实施诸如您描述的战术模式之类的通用系统时，可能会再次有所不同。
战略模式在更高的抽象层次上运行，包括有界上下文、上下文映射、无处不在的语言、模型/设计漩涡等。这些模式不受技术限制，适用于战术模式之外。从某种意义上说，它们也比战术模式更重要，并且无论底层技术如何都适用，因为它们更适合人们的思维方式而不是计算机的方式。因此，您仍然可以从通用域中的战略模式中获益。