因此，让我们说我们必须设计一个图书馆管理系统。现在，这可以通过域驱动的设计原则来完成，通过编写无处不在的语言，然后找出有界的上下文，创建聚合根，最后建立一个包含书籍，用户，作者等的对象模型。
但是，如果我们必须在Salesforce或Sharepoint的线上设计一个通用系统（具有设计和创建自定义表单和工作流的功能）。因此，首先我们将创建一个通用系统，可用于实现图书馆管理系统或任何其他系统，如人力资源管理系统等。
我们是否仍然可以在设计通用系统时应用领域驱动设计原则？如果，是的，那么在无所不在的语言中我们应该列出域名对象，如书籍，用户，作者，员工，部门等，或者我们应该只列出通用对象/名称值对/哈希表。因为，这个通用系统可用于实现任何其他特定于域的系统。
换句话说，如何在创建通用系统时应用域驱动设计原则？这可以用于以后实现其他特定于域的系统。
答案 0 :(得分：2)
我们是否仍然可以在设计中应用领域驱动设计原则 通用系统？
是的，DDD可以应用于您描述的通用系统。
如果，是，那么在无处不在的语言中我们应该列出域对象 像书籍，用户，作者，员工，部门等或我们应该 只列出通用对象/名称值对/ Hashtable。
对象和哈希表等名称不仅具有通用性，而且具有非常强大的技术内涵。无处不在的语言将由开发人员和领域专家共享，因此应该尽可能少地涉及技术含义。这并不是说诸如对象之类的技术名称是错误的名称 - 只需要了解您的域与支持技术基础架构之间的区别。即使所有领域专家都是开发人员，做出这种区分也很重要。
可以说DDD由两部分组成 - 战术和战略。战术模式具有技术性，包括诸如存储库，价值对象等等。这些模式通常具有针对每种语言和平台的特定表现形式。随着技术的变化，这些模式也最有可能发生变化。例如，如果将event-sourcing与DDD一起使用时，战术模式会有所不同。在实现诸如你所描述的通用系统之类的通用系统时，战术模式可能会再次不同。
战略模式在更高的抽象层次上运作，包括有界上下文，上下文映射，无所不在的语言，模型/设计漩涡等。这些模式不受技术限制的约束，并且适用于战术模式之外。从某种意义上说，它们也比战术模式更重要，并且无论基础技术如何都适用，因为它们更倾向于人们的思维方式，而不是计算机的方式。因此，您仍然可以在通用域中获得战略模式的好处。