我已经阅读了良好的设计模式来解决以下冲突的要求：1。）域模型（DM）不应该依赖于其他层，如UI和数据持久性层。 2.）DM需要与UI和数据持久层交互。哪种模式可以解决这种冲突
答案 0 :(得分：5)
我不确定您是否可以将其称为设计模式，但我相信您所寻找的是Dependency Inversion Principle (DIP)。
该原则指出：
一个。高级模块不应该依赖于低级模块。都 应该取决于抽象。
B中。抽象不应该依赖于细节。细节应该取决于 抽象。 - Wikipedia
当你将这个原则应用于传统的分层架构时，你最终会得到广泛采用的Onion/Hexagonnal/Port & Adapters/etc...。架构。
例如，代替基于基础架构详细信息的域的传统Presentation -> Application -> Domain -> Infrastructure，您可以反转依赖关系并使基础架构层依赖于域层中定义的接口。这允许域除了自身之外别无其他任何东西。
DM需要与UI进行交互
关于这一点，我看不到域应该知道UI的任何情况。
答案 1 :(得分：0)
这一切都归结为软件项目的用例。用例不指定项目中的任何类型的实现。只要您满足这些特定的项目要求，您就可以做任何您想做的事情。
满足这些项目要求需要基本构建块。例如，您无法使用去年的铅笔税打印业务报告，而无需打印实际数字。无论如何，您都需要这些数据。
然后数据库成为下一个实施级别。数据库中的所有内容都是完成用例所必需的基本构建块。如果没有它，你根本无法完成用例。
我们不希望我们的用户只拥有一个命令行SQL程序并完成所有用例，因为这需要永远。想象一下，每个用户都必须了解并理解软件背后的域模型，只需要确定要读取的值以确定标题屏幕的字体颜色。没有人会购买你的软件。
我们可能需要的不仅仅是简单的域模型来满足客户的用例。让我们构建一个程序，作为用户访问数据和更新数据的工具。我们可以简化执行此用例所需的知识和时间。例如，我们可以创建一个加载屏幕的按钮。
虽然模型，视图和控制器在我们看到的所有图表上都被视为彼此相邻，但它们确实属于彼此叠加。您可以拥有一个没有视图或控制器的数据库，但反之亦然。要构建视图或控制器，您必须知道要与之交互的内容。您仍然需要完成目的所需的基本数据（您可以在数据库中找到）。