域模型如何在不依赖于它们的情况下与 UI 和数据交互？
How can a Domain Model interact with UI and Data without being dependent on them?
我读过 好的设计模式 可以解决以下相互冲突的要求：1.) 域模型 (DM) 不应依赖于其他层，例如 UI 和数据持久层。 2.) DM 需要与 UI 和数据持久层进行交互。什么模式解决了这个冲突？
这一切都归结为软件项目的用例。用例不指定项目中的任何类型的实现。只要满足这些特定的项目要求，您就可以随心所欲。
有一些基本构建块是满足这些项目要求所必需的。例如，您无法在没有要打印的实际数字的情况下打印包含去年铅笔税的商业报告。无论如何，您都需要这些数据。
然后数据库成为下一级实施。数据库中的所有内容都是完成用例所需的基本构建块。没有它，您根本无法完成用例。
我们不希望我们的用户只拥有一个命令行 SQL 程序并以此来处理所有用例，因为那样会花费很长时间。想象一下，每个用户都必须了解和理解您的软件背后的域模型，只是为了弄清楚要读取什么值来确定标题屏幕的字体颜色。没有人会购买您的软件。
我们可能需要的不仅仅是一个简单的域模型来满足客户的用例。让我们构建一个程序，作为用户访问数据和更新数据的工具。我们可以简化执行此用例所需的知识和时间。例如，我们可以只制作一个加载屏幕的按钮。
虽然模型、视图和控制器在我们看到的所有图表上都被视为紧挨着彼此，但它们实际上是堆叠在一起的。您可以拥有一个没有视图或控制器的数据库，但反之则不行。要构建视图或控制器，您必须知道您正在与什么进行交互。您仍然需要完成目的所需的基本数据（您可以在数据库中找到）。
我不确定您是否可以将其称为设计模式，但我相信您正在寻找的是 Dependency Inversion Principle (DIP)。
原理说明：
A. High-level modules should not depend on low-level modules. Both
should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on
abstractions. - Wikipedia
当您将此原则应用于传统的分层架构时，您最终会得到广泛采用的 Onion/Hexagonnal/Port & Adapters/etc...。架构。
例如，不同于传统的 Presentation -> Application -> Domain -> Infrastructure 域依赖于基础架构细节，您反转了依赖关系并使基础架构层依赖于域层中定义的接口。这允许域只依赖于它自己。
The DM needs to interact with the UI
关于这一点，我看不出域应该知道 UI 的任何情况。
我读过 好的设计模式 可以解决以下相互冲突的要求：1.) 域模型 (DM) 不应依赖于其他层，例如 UI 和数据持久层。 2.) DM 需要与 UI 和数据持久层进行交互。什么模式解决了这个冲突？
这一切都归结为软件项目的用例。用例不指定项目中的任何类型的实现。只要满足这些特定的项目要求，您就可以随心所欲。
有一些基本构建块是满足这些项目要求所必需的。例如，您无法在没有要打印的实际数字的情况下打印包含去年铅笔税的商业报告。无论如何，您都需要这些数据。
然后数据库成为下一级实施。数据库中的所有内容都是完成用例所需的基本构建块。没有它，您根本无法完成用例。
我们不希望我们的用户只拥有一个命令行 SQL 程序并以此来处理所有用例，因为那样会花费很长时间。想象一下，每个用户都必须了解和理解您的软件背后的域模型，只是为了弄清楚要读取什么值来确定标题屏幕的字体颜色。没有人会购买您的软件。
我们可能需要的不仅仅是一个简单的域模型来满足客户的用例。让我们构建一个程序，作为用户访问数据和更新数据的工具。我们可以简化执行此用例所需的知识和时间。例如，我们可以只制作一个加载屏幕的按钮。
虽然模型、视图和控制器在我们看到的所有图表上都被视为紧挨着彼此，但它们实际上是堆叠在一起的。您可以拥有一个没有视图或控制器的数据库，但反之则不行。要构建视图或控制器，您必须知道您正在与什么进行交互。您仍然需要完成目的所需的基本数据（您可以在数据库中找到）。
我不确定您是否可以将其称为设计模式，但我相信您正在寻找的是 Dependency Inversion Principle (DIP)。
原理说明：
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions. - Wikipedia
当您将此原则应用于传统的分层架构时，您最终会得到广泛采用的 Onion/Hexagonnal/Port & Adapters/etc...。架构。
例如，不同于传统的 Presentation -> Application -> Domain -> Infrastructure 域依赖于基础架构细节，您反转了依赖关系并使基础架构层依赖于域层中定义的接口。这允许域只依赖于它自己。
The DM needs to interact with the UI
关于这一点，我看不出域应该知道 UI 的任何情况。