“事实reality”这个概念的定义是：以前所有事实的结果。
没有人知道过去的每一个事实。当我们分享一些事实时，我们并没有给予所有这些事实同等的重要性。我们根据我们相信的事实建立我们的“事实”概念，并根据自认为重要的事情就给予他们一些重要性。
换句话说，有好几个“事实”概念。它可以基于一些虚假的事实，但仍然是属于某个人的事实。
但是不要将其与真理的概念混淆：只有一个真理，问题是没有人知道它（提示：大多数人认为他们的事实是真理，康德的物自体概念）。
构建共享的抽象的“事实”（即软件）是非常困难。
意大利面条事实
这是DDD的重点，避免混合各种“事实”。
理解企业的“事实”需要大量的时间和分析。这是一个迭代的任务。领域专家分享“事实”，因为他们共享一些业务流程。例如，营销团队的某个人会从另一位同事那里了解营销，但她并不总是了解来自货运团队的同事。他们面临着不同的挑战，他们使用不同的语言：他们在不同的“事实”中工作。
来自DDD的战略模式帮助我们构建特定于上下文的解决方案，以便构建仅匹配一个“事实”的软件，从而避免通过共享抽象一个共同“事实”，因为后者是将“事实”误以为真理，在这个追寻所谓真理过程中却获得了难以管理的复杂程度。
如何选择事实
必要的复杂性是解决方案的最纯粹形式，意外的偶然的复杂性是指我们开发的解决方案比问题所要求的更复杂。
在Ben Moseley和Peter Marks的优秀的论文中，他们解释了我们是如何在软件中带来技术偶然的复杂性，特别是在状态控制（事情发生的顺序）和代码体积（代码的行数）。
我认为我们经常错过了寻找领域中偶然的复杂性的机会。我们认为问题已经很好理解，而大部分时间却都有改进的余地。
如何实现“事实”
如果我们同意“事实”的概念是指所有先前事实的结果，那么寻找表示这些事实的实施是有意义的。
这样的实现将更容易转化为事实，反之亦然。这样的实现有助于描述软件的本质：它是一个基于过去事实的自动决策者。
这种实施已经成为“事实”概念
用户向软件发送一个愿望（“我想这样做......）”，软件根据自己的现实（即它知道的事实）作出决定，并将反馈数据发送给用户以帮助她找到她的下一个愿望。
只需用事件替换世界“事实”概念，用命令实现意愿，通过用户反馈查询以查找这些概念的现有实现。