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

Question

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

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

我们仍然可以在设计通用系统时应用领域驱动设计原则吗？如果是，那么在无处不在的语言中，我们应该列出域对象，如Books，Users，Authors，Employees，Departments等，还是应该只列出通用对象/名称值对/Hashtable。因为，这个通用系统可以用于实现任何其他领域特定的系统。

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

Answer 1

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

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

如果是，那么在普遍使用的语言中，我们应该列出域对象，如图书、用户、作者、雇员、部门等，还是应该只列出通用对象/名称值对/哈希表。

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

可以说，DDD由两部分组成--战术和战略。战术模式是技术性质的，包括存储库、值对象等。这些模式通常对于每种语言和平台都有特定的表现形式。随着技术的变化，这些模式也最有可能发生变化。例如，如果在使用event-sourcing和DDD时，战术模式略有不同。在实现一个通用系统时，例如您所描述的系统，战术模式可能又是不同的。

战略模式在更高的抽象级别上运行，包括有界上下文、上下文地图、无处不在的语言、模型/设计旋涡等内容。这些模式不受技术约束，适用于战术模式之外。在某种意义上，它们也比战术模式更重要，并且无论底层技术如何都适用，因为它们更适合于人们的思维方式，而不是计算机的方式。因此，您仍然可以在通用领域中获得策略模式的好处。