域专家应该制作类图吗？

Question

我们团队中的领域专家使用UML类图来建模领域模型。

因此，类图更多的是技术模型而不是领域模型(它为开发人员提供某种技术规范，因为它们不需要做任何概念，它们只需要实现模型)。

最后，领域专家最终完成了架构师/技术专家的工作，对吗？

领域专家(不是开发人员或技术概要)做类图是正常的吗？

如果没有，他应该使用什么样的模型？

Answer 1

这实际上取决于类图中的细节级别以及它们的使用方式。

必须做出的一个重要区别是: UML类与编程语言类不相同。它表示可能以许多不同的方式实现的域概念(或者根本没有实现)。

定义这些概念是领域专家的一项工作。只要足够清晰(这是最困难的部分)，他们将这样做的具体格式并不太重要。因此，它可能是一个口头的描述，或者，在您的例子中，一个UML图。

现在的问题是，您的领域专家生成的这些UML图不需要，而且大部分时间不应该用作代码的蓝图。它们的存在只是为了使开发团队能够理解业务领域。然后，如果他们认为有必要，开发人员(包括系统架构师)创建了一个不同的模型，该模型还考虑到领域专家不知道的技术限制。此外，这种模式的格式也不是特别重要。它可能是另一个UML模型，但也可以是代码和项目文档的组合。

示例：

考虑一个银行软件系统。在这种情况下，领域专家是具有银行专业知识的人。他的工作是向开发团队传达业务需求，并且可以通过对银行使用的文档流建模来选择这样做。现在的问题是，这些文档(在打印和手工填写时所显示的形式)通常是非常不规范的，并且包含许多分散在不同表单上的冗余数据。领域专家生成的模型可能包含所有这些冗余，但开发实现的模型通常会在必要时消除这些冗余。然而，这两种模式在开发过程中都有其用途。

Answer 2

我现在的团队的业务分析师也是这样做的:)我不认为这很常见，但对于那些具有技术背景的人来说，这是一个典型的缺陷，他已经发展成为业务分析师/领域专家。

有许多方法来建模一个领域，从UML图表到白板上的文字，再到一张纸上的图纸。重要的不是模型的方面，而是它传达的内容。您还应该记住，域建模是协作工作，并意味着领域专家和技术人员之间的对话。业务专家单独生产所有模型(更不用说低级别技术模型)并将它们强加给开发团队的环境对我来说似乎有些不正常。

Answer 3

领域专家(不是开发人员或技术概要)做类图是正常的吗？

不，这是不寻常的事情，但总有一些例外。

域专家可以构建UML图来捕获业务流程和参与其中的参与者。这可能是他们能够为项目架构师和整个团队准备的最有用的文档。因为，有80至150页长的文档很难通过阅读来理解和可视化。换句话说，业务工作流、数据流和决策流程应该被该人员捕获。

然而，详细的类图确实需要领域驱动设计或面向对象建模的技术知识集，并对类图有很好的理解。