洋葱建筑设计问题
最近，我开始着手一个新项目，团队正在考虑使用洋葱架构，我对此并不十分熟悉，所以我开始阅读有关它的文章。
该应用程序是一个简单的三维格式转换器。它将读取sql数据库，转换数据，然后将新格式写入另一个MySql数据库。第一个数据库本身非常复杂，但我不认为它是mather。应用程序的概念非常简单:从A读取、转换、写入到B。我不会为它提供任何服务或特殊的基础设施。
它将是一个桌面应用程序。
基于这些事实，我要求：
- 我所读到的关于洋葱的一切都与网络应用有关。在桌面应用程序中，它不是很流行，有什么特别的原因吗？
- 我还读到它在复杂的企业中表现得最明显。在这样简单的应用上，它会否有效及有实际的优势？
- 如果我们选择洋葱路径，域层中会有什么？请自由评论以下几层: L1)源层:将表示源数据库 L2中的数据)输出层:将表示输出database L3中的数据)数据库读取器层:将负责读取源数据库和填充层1 L4)转换层:将是一个适配器，它将接收第1层，并将第2层填充到转换后的data L5)数据库写入层:将第2层写入数据库将是第1层和第2层是我的域层吗？第3层和第5层是基础设施吗?和第4层是应用程序或域服务吗？
回答 2
Software Engineering用户
发布于 2016-05-31 21:13:29
在这种情况下，我不太确定洋葱结构是否有意义。
您可以从洋葱体系结构中保留的原则是，您的应用程序核心(译者)应该与数据访问分离。但总的来说，您的需求更像是一条管道。
read -> transform -> write
现在，读和写是不纯的(很难测试)。如果转换不直接调用写，则转换可能是纯的(易于测试)。因此，如果您通过让应用程序的核心(transform)返回要写入的数据，或者发布到队列/可观察/总线来实现解耦，那么您已经有效地隔离了您的核心，并使其可测试。这就是洋葱结构的原理。
关于你的问题：
- 通常，服务器应用程序具有复杂的业务逻辑，但没有理由不将模式应用于任何其他类型的应用程序。
- 将核心功能从接口分离到其他系统总是有好处的。
- 域层将是您的DBs最终要表示的业务实体。
在我看来，是否选择“公共”对象类型和更类似于数据库中的表示的两个对象类型是可能的，但不是严格的要求；这取决于数据的类型。您可以使用关系模型作为域模型，并将其转换为非规范化模型。(我看到许多应用程序在层间复制相同的对象，最终得到许多相同数据的表示；这不是一个很好的设计，海事组织。)
Software Engineering用户
发布于 2016-05-26 20:25:46
您的输入数据库和输出数据库都位于第一层。
第二层将包含两个转换器，一个对应于第一层的每个数据库，在特定的数据库对象和“公共”(或“通用”)对象类型之间进行转换。
第三层，您的“应用程序”，操作公共对象。
你可以把它看作是一条弯曲成"U“形状的管道。
https://softwareengineering.stackexchange.com/questions/319559
复制相似问题
腾讯云开发者
