Use Case Driven Data Modeling with UML : Theory and Practice 阅读笔记(1)
长久以来一直致力于系统性地研究相关内容。与此同时熟悉了模型驱动开发模式的基本概念。为了巩固相关知识背景特意复习了UML的基础内容。通过网络渠道采购到了一本名为《Use Case Driven Data Modeling with UML : Theory and Practice》的专业书籍。鉴于当前拥有充足的学习时间安排表。采用笔记形式作为学习辅助工具帮助梳理知识点。今天开始尝试以一种笔记的方式来驱动我的读书过程。顺便记下我的读书心得希望由此获得预期的学习效果
今天阅读它的第一章：Domain Modeling, 掌握其汉语含义即为理解域建模的概念。在众多项目中, 项目成员之间的沟通往往因为使用不同的描述语言而导致彼此间存在误解。正是由于这些挑战的存在, 因此而产生域建模这一概念。
看原文：
The domain model is an alive, collaborative nature. It is continually refined and updated throughout the project, so as to consistently reflect the current understanding of the problem space.
现在明白了！域模型旨在通过深入理解当前问题空间来构建数据模型，并且，在项目开发过程中不断提炼与更新以适应需求变化。
下面这句话再明白不过的了：
本章我们将探讨域建模技术，并旨在通过建立一个共同词汇表来明确项目中的沟通问题。
域模型主要用于解决项目中因沟通错误而导致的问题。通过创建一个统一的术语库来定义问题领域以减少歧义。
领域建模代表了构建项目词典的过程，即以这个词典的形式记录项目中使用的术语。
域建模是用来构建工程词库的任务，构建一个在项目中使用的词典。
Domain models for projects establish their scope and upon which you can build use cases.
一个项目的域模型定义了用来构建用例的范围和形式。
A domain model additionally offers a shared terminology so that effective means of clear communication can be established between members of a project team.
域模型引入了公共术语表，并且通过该术语表促进项目成员间有效信息的交流。
Despite this book focusing on use case–driven development, we must start with domain modeling as its foundation.
这也正是由于，在介绍用例驱动开发的一本书中开篇
As just referred to, a domain model represents essentially a project glossary: an interactive dictionary of all the terms used in your project.
可以说域模型就是项目中的核心词汇库——它实际上是一个包含了项目所有术语的详细记录。
However, a domain model supersedes a reference glossary; it graphically illustrates how all these various terms interrelate.
域模型不仅是一本词典，因为它还会显示各个词之间的关系。
In actual practice, it is a simplified class diagram. Additionally, connections are made between various classes (domain objects) using lines to illustrate their relationships with one another. The domain model illustrates both aggregation and generalization relationships, specifically highlighting has-a and is-a relationships among the domain classes.
域模型包含两种关系，聚合和泛化即has-a 和 is-a的关系。
Our guidance is predominantly against that approach: your use case descriptions must be based on real-world scenarios and closely aligned with the system you plan to develop. To elaborate further, all use cases should reference domain objects by name within an object model context. By implementing this approach, you will help integrate static and dynamic aspects of your model into a cohesive framework, making it a driving force for advancing your analysis and design efforts.
我们建议您在撰写用例正文时，请确保内容紧密围绕当前系统的设计需求，并紧密围绕当前系统的设计需求进行阐述；即应着重结合实际应用场景来进行描述；从而将系统的动态行为与其静态结构有机融合；若希望用例成为分析与设计的核心依据，则需要特别注意这一点。
在撰写使用场景之前，请您先构思一个初步版本的领域模型。领域模型构成了静态部分的基础框架，在此之上构建的是系统的静态特性与关系；而使用场景则构成了动态部分的基础依据，在此之上发展的是系统的动态行为与交互流程。
因为编写用例之前需要考虑系统的静态结构基础，并为后续的功能运行奠定理论支撑，在此阶段应充分顾及到系统的整体架构设计与实现细节
Top 10 Domain Modeling Guidelines
10. Focus on real-world (problem domain) objects.
When constructing a domain model, it is advisable to emphasize objects that are relevant to the problem context. Structuralizing your software architecture based on the real-world patterns can enhance its effectiveness. The real world undergoes relatively infrequent changes compared to software requirements.
构建领域模型时,应专注于问题空间中的现实世界对象,并努力以现实世界的结构组织软件架构.现实中变化的频率远低于需求变更.
Use generalization (is-a) and aggregation (has-a) relationships to demonstrate the manner in which objects establish relationships with one another.
These key connections, including both these and standard (plain vanilla) associations, represent the most critical linkages within your domain model. Ninety-five percent of your model's class relationships are typically modeled as aggregations or generalizations.
构建对象之间的is-a和has-a关系。这些关键的关系对于您的领域模型至关重要，在您的领域模型中具有核心地位的这类关系几乎可以全部通过这两种基本类型来建模
8. Limit your initial domain modeling efforts to a couple of hours.
We advise setting aside a time allocation for constructing your initial domain model. Approximately two hours suffice as a guideline. There’s no need to aim for perfection; proceed with the task at hand, and plan for adjustments as needed. Maintain vigilance in refining your analysis-level class model based on findings from robustness testing and ongoing project developments.
可以考虑设立一个时间段以确保为构建最初的领域模型预留充足的时间基础；建议采用几小时到十小时的时间段较为合理；无需追求完美可以在初步构建阶段注重效率与速度；随后在后续步骤中进行完善和优化以提升整体质量
在健壮性分析以及真实项目进程中出现新的发现时，在分析层次对类模型进行相应的调整，并始终保持着高度警惕。
As you work through use cases and robustness diagrams, you will find missing objects. It assumes that the domain model is incomplete and offers a way to identify what was missed.
当你在用例部分和健壮性分析过程中会发现遗漏的实体时, 该开发过程基于域模型不完全的情况, 并具备了发现遗漏问题的能力
The starting domain modeling session is undoubtedly the most crucial two hours invested in this project. Anticipating, participants will likely encounter 80% of their domain classes during this two-hour brainstorming period. Achieving 80% of your domain vocabulary disambiguation would make these two hours highly rewarding.
花费两个小时来发现百分之八十的域词汇，这样就很不错了。
7. Organize your classes around key abstractions in the problem domain.
It's advisable to structure your classes around core concepts within a problem domain. Recognize that a foundational class diagram represents your domain model, which serves as an architecture basis for software development. This renders it resilient when challenges arise. Arranging architecture based on real-world abstractions renders it adaptable to varying requirements, since those vary more often than reality itself.
在组织类时遵循以下原则：以问题空间的关键抽象为中心；请注意，在软件架构中，默认的是基于领域模型构建初始类图；这样的做法有助于使系统在面对变更时更加灵活；基于现实世界中的抽象组织架构；这样的设计能够更好地应对实际需求的变化；通过这种方式可以提高系统的适应性和可维护性
6. Don’t mistake your domain model for a data model.
Even if the diagrams appear alike, it's important to note that best practices applicable to a data model are unlikely to be effective for class diagrams, and vice versa. Class diagrams typically involve smaller components compared to entity relationship tables. In relational databases, entity relationship tables often connect multiple entities within the same system. Conversely, class diagrams are better designed when they represent relatively small, focused units of data and behavior.
Typically, within a class diagram, one can expect to encounter a class dedicated to managing a database table. It is common to incorporate instances of a TableManager class when dealing with aggregating regular domain classes. Such classes are typically designed to encapsulate and abstract away the complexities associated with managing databases through systems like DBMS.
Don’t misinterpret an entity (which stands for a unique instance) as a data structure (which holds a group of items).
一个对象代表某类事物的一个实例。而数据库表则代表一类事物的集合。你不必像在Enterprise JavaBeans（EJB）世界中那样字面化，在那个世界中一般情况下一个实体Bean对应的是单个表格中的一个行。然而，在Domain领域中情况有所不同。如果你提到的是Domain类Book，则不是指整个书库表（book table），而是指单一的一本书。
表格中的列通常对应于类的属性。不过需要注意的是，在大多数情况下数据库表会包含大量的列（通常包括外键等），因此每一行并不总是与一个对象存在直接的一一对应关系。
4. Use the domain model as a project glossary.
If ambiguous requirements challenge you, the domain model is your first line of defense. The ambiguous usage of names by subject matter experts abounds and is highly detrimental. The domain model should act as a project glossary, aiding in consistent term usage when outlining the problem space. Adopting the domain model as a project glossary represents the initial step toward disambiguating your model. In every Jumpstart workshop Doug teaches, he notices at least two or three domain classes where students are using ambiguous naming conventions such as "shopping cart," "shopping basket," or "shopping trolley."
Construct an initial domain model prior to drafting your use cases, to prevent name ambiguity.
借助于域模型来消除您在概念化过程中遇到的歧义性，
创建基于歧义术语的用例是没有意义的，
因此，请在编写用例之前投入两小时专注于构建您的领域模型。
如果不借助领域模型将所有内容联系在一起编写用例，则会留下许多潜在的问题待解决。
Avoid expecting your final class diagrams to exactly conform to your domain model; however, there should be any resemblance between them.
As design progresses, class diagrams will far exceed in complexity compared to the domain model; this latter construct is intentionally maintained at a minimal level. When employing sequence diagrams for design purposes, intricate elements such as GUI helpers, factory classes, and infrastructure classes are integrated into the class diagram. Moreover, during this process, it's probable that the domain model diagram will bifurcate into several specialized class diagrams. Notably though, most of these constructed elements can still be traced back to their corresponding core domain constructs.
1. Don’t put screens and other GUI-specific classes on your domain model.
Doing so unleashes Pandora’s box and results in a highly cluttered domain model that encompasses numerous implementation-specific details. Performance optimization classes, along with any supplementary classes, must be excluded from the core domain model. The primary focus of the domain model should be solely on addressing problems within it.