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