UML中的域模型？ [英] Domain models in UML?

问题描述

我了解了域模型及其重要性，并且有以下疑问：

I read about domain model and its importance and I have the following doubts :

• 一个问题可以解决什么问题与域模型？换句话说，对于每个问题，我都应该构建一个领域模型？

• What kind of problems can one resolve with domain models? in other words,for each problem I should build a domain model?

据我所知，领域模型是使用类图表示的。类图和领域模型之间的区别？

As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?

我还想了解词汇与领域模型的联系方式是什么？

I also would like to understand In which way is vocabulary related to a domain model?

推荐答案

域模型可以解决哪些问题？

What kind of problems can one resolve with domain models?

几乎您想要/需要提供软件解决方案的任何问题都可以建模。实际上：无论您做什么，都必须以某种方式，形状或形式对问题域进行建模。如果您不以某种方式捕获软件问题的规则和策略，那么最终系统就不太可能满足其预期的要求。

Pretty much any problem that you want/need to provide a software solution for is amenable to modelling. In fact: however you do it, you must 'model' your problem domain in some way, shape or form. If you don't capture the rules and policies of the problem in software somehow it's pretty unlikely the end system will meet its intended requirements.

换句话说，对于每个问题，我都应该构建域模型？

in other words,for each problem I should build a domain model?

这取决于您构建域模型的含义。

It depends what you mean by 'build a domain model'. See above and below...

据我所知，领域模型是用类图表示的。类之间没有区别图和域模型？

As far as I know, The domain models are represented using class diagrams .there is no difference between class diagram and domain model?

类图是对域建模的一种方法。实际上，它们是对域的一部分进行建模的一种方法。类图的主要优点是，它可以清楚明确地暴露问题空间中的关系。有一种观点认为，域的语义主要是通过概念（类）之间的关系产生的，而不是类本身。如果您对此表示赞同，那么有可能/可能会发现有用的类图。

Class Diagrams are one way to model a domain. Actually, they're one way to model part of a domain. The primary advantage of a Class Diagram is that it exposes the relationships in the problem space explicitly and clearly. There is a body of opinion that says the semantics of a domain arise primarily through the relationships among concepts (classes) - more so than the classes themselves. If you buy into that opinion then it's possible/likely that you'll find a class diagram useful.

但是请注意，类图仅捕获域的结构元素：类，属性和关系。 CD无法捕获行为。如果要以任何有用的方式对问题空间进行建模，则域模型既需要结构，又需要行为。因此，您需要使用一些行为描述来扩充类图；例如状态模型和/或动作。

Note however that Class Diagrams only capture the structural elements of a domain: Classes, Attributes and Relationships. A CD doesn't capture behaviour. A Domain Model needs both structure and behaviour if it's to model the problem space in any useful way. So you'll need to augment the class diagram with some behavioural description; e.g. state models and/or actions.

还有其他方法可以对域进行建模。它可以是一组java / c＃类。这种方法的主要缺点是对关系的重视程度降低。与类图不同，OO语言不提供作为一流构造的关系。优点是，与大多数建模工具相比，编程语言环境（编辑器/编译器/库/语言运行时）为定义域的行为方面提供了更好的支持。

There are other ways to model domains too. It can be a set of java/c# classes. The main disadvantage of such an approach is the reduced emphasis on relations. Unlike class diagrams, OO languages don't provide relations as first class constructs. The advantage is that programming language environments (editors/compilers/libraries/language runtimes) provide much better support for defining the behavioural aspects of a domain than most modelling tools.

更普遍地，没有规则说域模型必须遵循OO范式。它可能是Haskell或OCAML中的一组函数和类型。也许是一些微分方程或其他数学构造。

More generally there's no rule that says a Domain Model has to follow the OO paradigm. It could be a set of functions and types in Haskell or OCAML. Or it could be some differential equations or other mathematical construct.

关键是该模型（无论表达如何）都提供了对问题空间的描述。为了使描述不是完全的有用，它只会捕获问题空间中与系统要求相关的属性的子集。为了有用，但是它应该是正确的- 捕获的概念和行为应准确反映正在建模的世界。

The key thing is that the model - however expressed - provides a description of the problem space. To be useful that description will not be complete - it will only capture the subset of properties in the problem space relevant to the system requirements. To be useful however it should be correct - the concepts and behaviour that are captured should accurately reflect the world being modelled.

我还想了解词汇以哪种方式与域模型相关？

I also would like to understand In which way is vocabulary related to a domain model?

您可以将域模型视为产生形式化和高度结构化的词汇的一种方式。实际上，它也捕获了一些语法。例如它说所有权关系的参与者必须是狗和人；不是两只狗，也不是一个人和一把勺子。

You can think of a Domain Model as a way to produce a formalised and highly structured vocabulary. Actually, it captures some grammar too; e.g. it says that the participants in the 'Ownership' Relation must be a Dog and a Person; not two Dogs, or a Person and a Spoon.

这就是埃里克·埃文斯（Eric Evans）在域驱动中所说的无所不在的语言设计。这意味着模型中使用的术语应准确反映所建模问题的术语。因此，如果现实世界中的专家使用人和狗这两个词，则该模型不应使用智人和犬。理由很简单：如果开发人员（建模人员）使用与领域专家相同的术语，那么误解的机会就会大大减少。因为每个人都使用具有共同含义的熟悉的单词，所以它也导致了更富有成效和愉快的对话。

This is what Eric Evans calls 'Ubiquitous Language' in Domain Driven Design. It means that the terminology used in the model should accurately reflect that of the problem being modelled. So if the real world domain experts use the words 'Person' and 'Dog', the model shouldn't use 'Homo Sapien' and 'Canine'. The rationale is simple: if developers (modellers) use the same terms as the domain experts, there's much less chance of misinterpretation. It also leads to more productive and pleasant conversations since everyone is using familiar words with a common meaning.

摘要

• 域模型是一种抽象。它代表了系统要解决的实际问题的内在概念，规则和策略的子集。


• 类图是表示域模型的结构方面的一种方法。它没有捕获动态方面。这些同样重要。


• 还有其他建模域的方法。它们不仅限于面向对象的范例。


• 领域模型应该是问题空间的结构化词汇。它应该采用该领域专家使用的术语。

• A Domain Model is an abstraction. It represents a subset of the concepts, rules and policies intrinsic to the real-world problem the system addresses.
• A Class Diagram is one way to represent the structural aspects of a Domain Model. It does not capture the dynamic aspects. These are equally important.
• There are other ways to model a domain. They are not limited to the Object-Oriented paradigm.
• A Domain Model should be a structured vocabulary for the problem space. It should adopt the terminology used by experts in that field.

hth。

这篇关于UML中的域模型？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！