业务领域建模Domain Modeling

1、Collect application domain information – focus on the functional requirements – also consider other requirements and documents

创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织您的软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，您将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。

 

2、Brainstorming – listing important application domain concepts – listing their properties/attributes – listing their relationships to each other

随着时间的推移，您将会使用新的领域类别来识别您的领域模型。您还会注意到他们之间的联系（或关联） - 例如，书评属于书，采购订单（purchase order）和信用卡（credit card）是两种，因为它们都是付款类型。
第一个关系（书评属于一本书）被称为聚合（has-a，因为一本书都会有一书评）。第二个关系（采购订单和信用卡都是付款类型）被称为泛化（is-a，因为采购订单是付款类型）。这些所谓的一般关系是您的领域模型中最重要的关系。您可以使用聚合和泛化关系建模您的模型的类关系中的百分之九十五。尽可能不要使用“关联”，使领域模型从左到右和从上到下阅读，就像普通文本一样。 这将提高您的图表的可读性。

 

3、Classifying the domain concepts into – classes – attributes / attribute values – relationships

一个对象代表一个单一的东西。数据库表表示事物的集合。您不必像企业JavaBeans（EJB）世界中的文字一样，实体bean通常表示表中的单个行。领域类是相似的。如果你调用一个领域类图书，那么并不意味着书表（数据库里面没），而是是一本书。数据库表中的列通常映射到类上的属性。
但是，数据库表通常包含比包含属性更多的列（表通常具有外键作为一个示例），因此表行和对象之间可能没有直接的1：1映射。

 

4、Document result using UML class diagram