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