概念、实体、数据三者之间区别？

概念、实体、数据三者之间区别？ - 极道

假设一个场景：与客户讨论开始新的工作：

客户：我们的用户需要处理三种不同类型的任务：快速任务、复杂任务和监督任务。
我们：它们之间有什么区别？
客户：快速任务只是登记某人做了某事。真的很简单。
我们：嗯。
客户：复杂的任务比较麻烦，需要特殊设备和资格卡。
我们：监督任务呢？
客户：监督任务需要监督人员的关注，并给予评估反馈。而且，这些任务可能有多人参与。
我们：重要的是要记住，无论是复杂任务还是监督任务，都可能需要一些时间，我们需要知道他们的时间，我们需要知道他们的状态。

亲爱的读者，你的直觉是什么？

我们应该使用一个单独的任务表，还是每个任务都使用一个表？监督任务、复杂任务和快速任务？
那么我们可能还需要将资格卡、监督员和评估作为单独的表来表示。
啊，我们差点忘了多人参与 ComplexTask 的问题--我们的客户对底层职业的正确名称只字未提，我们就叫他们工人吧。
此外，在幕后我们还得到了更多细节，即所有类型的任务都与共同的数据集相关，例如 Worker。

语言是流动和消失的东西，它不是有形的，也可能是不稳定的。

让我们来勾勒一下：

正如您所看到的，我们可以进行扩展，因为我们有任务类型TaskType和任务状态表TaskStatus，以防客户改变主意。很聪明，不是吗？

有什么问题吗？
你可能已经对我有所了解了（我希望如此，亲爱的读者！）--我喜欢夸大其词。

我故意把注意力集中在名词上，完全忘记了问一些非常重要的问题：

• 我们的用户是谁？
• 他们将如何使用我们的系统？
• 目前满足他们需求的方式是什么？
• 这个系统应该如何帮助他们实现目标？

等等。
当然，我轻描淡写地举了个例子。

但是，在我们的日常对话中，有多少时候我们会听到状态、状态标志、实体、数据模型？
我们有多少次以 "两个实体共享相似的数据集 "为前提，并假设它们可能由同一个实体来表示？

在我们的这个演示案例中，"任务"（Task）可能被表示为一个基类，这样我们就可以避免数据重复。

没有人会反对 QuickTask 是一个任务（Task），对吗？

寻找关系
我们寻找层次，寻找事物之间的联系。

如果我们放慢脚步，扪心自问--我们想象中的客户描述了什么？

从我们称之为 "声音 "的非结构化、模拟音频信号中，我们诠释了这些词语，使它们变得更有条理。

立即关注名词、名词之间的关系，并可能关注属性（也称为数据）。

事实上，从实体关系图（ERD）的角度来思考，可以帮助我们找到所有这些关系，ERD 可能与在 SQL 数据库等持久性工具中有效表示实体和数据有关。

说到建模，这可能被认为是一个相当低的层次。

这只是一个层次--还有更多。

先有什么？实体还是实体？
在开始绘制 ERD 草图之前，让我们回想一下从故事一开始的讨论中听到的内容。

我们如何称呼所有突出显示的 "事物"？
人们用来称呼这些 "事物 "的首要标签是实体。

每个实体都有与之相关的数据。

这个词带有偏见，很容易让我们陷入非常具体、狭隘的思维中。

为了避免我们的思维与 TDD 和 DDD（表驱动开发和数据库驱动设计）纠缠不清，我喜欢用另一个词。

我喜欢用“概念Concept”标签来表示这些 "东西"。

"这只是一个概念Concept"--我不知道技术上如何实现它。

我什么都不期待，所以我做好了一切准备。
不被来自执着领域的锚束缚，就能获得解放。
我们现在可以打破常规。

概念Concept的本质是什么？
我们不需要问自己 "一项任务可以有多少设备？"- 这是次要的。
我们不需要考虑 "资格卡 "是否有名字，它的最大长度是多少--这不会造成问题。

概念没有状态，实体才有。

考虑到这一点，我们可以玩一玩概念这个名称："已完成的快速任务 "有存在意义吗？它与 "已完成的复杂任务 "有区别吗？

记住，我们现在讨论的还不是技术实现！

在我的脑海中，概念可以自然地出现和消亡--当然不是字面上的意思。

• 它们可以通过相互转换而产生和消亡。
• 它们经过加工，演变成其他概念。

快速任务会变成复杂任务吗？
让我们设想一下，我们的客户被问到："一项快速任务会不会因为一些意想不到的复杂因素而无法完成？
假设客户回答是的，那么任务类型就会从 "快速 "变为 "复杂"。

(虽然有些业务人员受到了数据库驱动设计的伤害--但我们需要帮助他们）

很抱歉，这听起来根本不像表达问题本身的语言。

很有可能，答案会有点不同："是的，快速任务最终可能会变成（Become a）复杂任务"。

"Become a（成为、变成）"

• 是非常重要的表述
• 是建模成熟度等级中的最高级别。

如果我们仔细倾听自己的心声，就会发现日常生活中的各种概念正是以转化的形式表达出来的。

生生不息

我们迟早会意识到，我们会很自然地想到，例如，一份重要文件变成了 "已签名"，或者背包里的旧三明治变成了 "腐烂"。

至少在我看来，用概念进行思考提供了这种可能性。

概念无法编译
是的，概念是第一步--它们不会产生任何错误，也不会导致服务器宕机（或者会吗？）

当然，有人可能会说我们在制造不必要的复杂性。
有人可能会说--"你把以前比较简单的事情复杂化了！"。

建模的成本增加了！

概念能对围绕问题域语言的 "事物 "进行建模：（banq注：围绕问题语言，也就是问题的上下文）
没有人说我们必须在代码中体现一切。

考虑到这一点，我不知道--如果我们的概念不是关系型的，而是图形型的呢？
也许并不存在我们从 SQL 数据库中了解到的关系。
我们该如何持久化我们的概念，又该如何在应用程序中表示它们--这些都是我们需要在某些时候向自己提出的完全不同的问题。
它们会出现的，不用担心。
（如何持久，是关系还是图形属于解决方案域，正如去医院看病，医院必须找出你身体的问题，也就是确认是什么病，至于如何治病是属于解决方案，不是问题域）

概念映射：从直线到箭头实现状态转换
让我们回到我们的小案例，快速任务变成复杂任务。
我们知道，复杂任务有一些与之相关的状态，对吗？

了解了这一点，让我们设想一下，我们的客户告诉我们，他们认为以下状态是有效的：

• 进行中（ongoing）
• 已分配（assigned）
• 已拒绝（rejected）
• 已阻止（blocked）
• 失败（failed）

实体关系图捕捉到了 "域 "的静态部分。
它有自己的用武之地，但在 "领域建模 "时却不适用。

例如，当我们使用关系数据库时，它可能会大有用武之地。
因此，现在让我们试着把每个 "状态 "和复杂任务结合起来，将其视为一个独立的......概念。

这种有有箭头的概念网可以称为 "概念图"。

它能帮助我捕捉概念的转换本质，并从最高级别--"成为became a"--建立模型。

更重要的是，用户很有可能可以在 "Blocked复杂任务 "上执行某种操作，但却无法将其应用到 "Assigned复杂任务 "上。

这些都是我们需要针对每个概念提出的额外问题，幸好它们都位于建模成熟度等级的 "中间 "层。

亲爱的读者，你可能已经注意到了，它与有限状态机非常相似。
试着向你的业务人员介绍一下有限状态机，不知道他们会有什么反应。

什么是数据？
我们不应忘记每个企业和人类事业中非常重要的方面--数据。
我们也可以称之为信息--只是为了打破持久性领域的锚定。
它与我们的生活息息相关，并占有一席之地--也许并不是从第一天起就直接占有一席之地。

在我们的概念图中，每一个过渡都可能需要非常精确的细节。
如何存储这些信息并不是我们最关心的问题--至少不应该是。

实体仇敌？
我是实体憎恶者，在抱怨数据的无关性吗？
算是吧。

"万物皆有其位，万物皆有其所"。

我认为，在特定的阶段（上下文），它们可能无关紧要，而在另一个阶段，它们却扮演着最重要的角色。
如果我们不利用我们的卓越技术，我们的用户就可能从我们的系统中获得价值。

我们不应该限制自己去探索其他人类使用的语言中的概念。

我们的概念并不附带布尔标志 IsValid 或 IsActive，尽管它们在技术上可能是这样实现的。(当谈到布尔时，您可能会对 "布尔是否有害？）

当我们从概念转向实体时，我们最终可能会谈论行为和责任。
然后，我们可能会从实体过渡到数据，因为我们需要使用信息。

这样的过程不会是离散的--它肯定会是动荡的、混乱的、流动的和充满新意的--就像生命一样。

下次，亲爱的读者，当你开始工作时，问自己一个问题：

我现在的推理水平如何？