问题标签 [onion-architecture]

我目前正在研究领域驱动设计，并尝试将其应用于 WPF 项目。我观看了一些教程视频，并阅读了许多文章，例如：

• 同一层的洋葱架构依赖关系：基础架构和 Web 通信
• http://eohmicrosoft.blogspot.fr/2012/08/laying-it-out-onion-architecture.html
• 领域驱动设计：领域服务、应用服务

我理解对接口和控制反转的关注。我读到有一些经常性的层名称（表示知识领域的域/核心，持久性的基础设施，应用程序......我不明白），但它们会根据我阅读的文章而改变。有的甚至没有出现。

是否有可能列出所有层，理论上，洋葱架构中需要这些层来面对所有需求和问题，以及它们的意图（它们包含什么样的代码，它们试图满足什么样的需求？ ，他们需要参考哪一层），好吗？

我正在使用 DDD 进行项目，我有一些课程，但我不知道将它们放在哪里。

该域是关于现有游戏的。该游戏具有基本概念，例如角色，技能树。我的领域类只是代表这些概念。我没有制作这个游戏。

我的应用程序/项目是关于拥有一个代表这些概念的软件，并具有一些附加值。目前，名称和描述是唯一可能的附加值（例如，“火法师”和“法力依赖，小心！”）。

问题1：有两个类是否有意义，还是应该合并它们？在前一种情况下，我应该将此类“具有附加值（名称和描述）”放在哪里？在应用层？

问题2：我说领域层代表我正在研究的知识领域，应用层代表领域中不存在但我想提供的所有东西，作为附加值，我说得对吗？

（因此，如果我的软件只是代表领域，应用层很薄，如果我的软件提供了很多非领域功能，那么应用层很厚？）

附加信息 1：我的项目是关于创建一个角色模拟器。因此，为了模拟一个角色，我必须表示它，以及它的所有依赖项。我的领域层职责是代表游戏。它包含像 Character 这样的类，具有一些属性（Life、Mana、Attack、Defense、Class）和一些枚举（如 CharacterClass，它列出了所有可用的类）。

现在，我希望我自己的项目能够为用户提供创建代表游戏角色的项目的能力。该项目还允许用户保存其他信息，例如当前项目的名称、主要（和次要）设备集、主要（和次要）技能树。任何设备集和技能树都可以使用注释，因此用户可以简单地拥有一个内置的备忘录/便利贴。次要装备集和技能树，注释不是游戏中现有的概念（因此，在我的领域中不存在）。

问题1中，“增值类”是一个角色项目，是多个信息（角色装备、技能树、注释等）的集合。如果用户需要，它可以保存在物理支架上，稍后再次打开和编辑。

问题 1 的重新表述：我有一个 Character 类和一个 CharacterProject 类。CharacterProject 类是多个信息的组合。但它特定于我的应用程序。把它放在应用层、领域层或其他地方有意义吗？

假设您有一个需要 2 个服务的应用程序，例如。Application, Service1,Service2

您是否应该按照这种洋葱架构构建额外的间接级别并将其中一个服务提升为应用程序服务，并将另一个降级为域服务。

或者你应该Application直接连接到两者Service1吗Service2？

通过另一个级别的间接，您可以减少对层的依赖Application，尤其是对外部服务，例如。'Paypal'、'Facebook'、'Cyber​​Source' 并创建更适合您的编程范式的应用程序服务适配器。毕竟，让所有开发人员熟悉所有这些广泛多样的 API 确实不利于生产力。Façade/Adapter 将使事情更容易开发，同时保护应用程序免受基础设施变化的影响。例如。该公司在 Cyber​​Source 上失败了，决定改用 Paypal，幸运的是，您的应用程序被屏蔽了，您只需要更改适配器即可。

也就是说，适配器肯定会造成不灵活。随着应用程序复杂性的增加，适配器也变得泄漏。那么您可能会遇到 3 个问题：泄漏抽象、惰性层（由于有太多孔而做得不够的层）以及违反通用闭包原则，因为任何时候您需要更改 UI，您不仅要修改您的应用程序，还有您的适配器。

当Service2已经是同一家公司的内部服务时会发生什么？你还应该为每个子系统创建一个适配器吗？如果你的团队很小怎么办？如果您拥有数十个拥有不同技术的团队怎么办？是否有关于添加另一层间接与直接调用服务的适当性指导？

根据上面的插图，我有项目布局。

我想编写一个带有接口 ISessionManager 的“SesisonManager”，使用我的容器将其连接起来并将其注入我的服务层。UI 和基础设施层是最外层，此时只有核心作为依赖项，据我所知，这是正确的方法。

我的 SessionManager 看起来像这样。

这将通过构造函数注入到服务中，当我需要 ISession 时，我只需调用 GetSession。当 SessionManager 被释放时，事务将被提交或回滚，具体取决于发生的情况。

这一切都有效，除了我不知道在哪里存储接口和实现。它不应该留在基础设施中，因为服务层依赖于它并且它是上面的一层。（根据洋葱标准，这很糟糕）。

我不能将接口放在核心中，因为我需要依赖于 Nhibernate .. 所以不知道到底该怎么做。我正在考虑制作一个公共/共享层并让它充当中间人，但不确定这是处理事情的正确方法。

任何帮助将不胜感激。

我正在学习 ServiceStack 和 Onion 架构，我有一个看起来很基本的问题，我觉得我错过了一些东西。

我有三个项目，一个 Api、Core 和 Infrastructure。

我在 API 项目中有 ServiceStack。我的核心项目中有我的实体对象，我的数据访问类在我的基础设施项目中。我必须用属性装饰我的实体对象，以便 Orm Lite 代码知道如何处理它们（创建表等）。这些是 [AutoIncrement] 和 [Index] 等属性。

我必须在我的核心中引用 ServiceStack 才能访问属性，而到目前为止，核心还没有依赖任何东西，这打破了洋葱架构的想法。

我错过了什么？我如何允许基础设施项目中的 OrmLite 在实体处于核心时处理我的实体的数据访问？

我正在为复杂系统的重新架构提出建议和原型。它是一个 n-Tier 分布式架构，大致遵循 DDD 的原则，并具有 Jeffery Palermo 的Onion Architecture的元素，尤其是 Domain Model/Services 的核心概念的分离（这些与领域问题密切相关，有些可能最终是自然而然的）实现为远程 WCF/工作流服务）从更高级别的应用程序模型/服务概念（组件通常代表应用程序/UI 代码协调操作，并将作为依赖项注入这些应用程序）。

我需要将这种方法传达给没有大量接触面向服务的架构、SOLID 原则、依赖注入、复合应用程序等的高管和/或开发人员。我遇到了对“应用程序服务”概念的一些重大阻力没有被实现为 WCF 或“Web”服务。

对我来说，“服务”只是实现某种“服务契约”的组件，“服务消费者”和“服务提供者”可以抽象地达成一致，这并不意味着它一定是“网络服务”，监听某些服务器上的端口。然而，我似乎根本无法理解这一点——它似乎太微妙或太抽象了。

我认为我只需要另一个术语“应用程序服务”来将其与“Web 服务”区分开来，但是“API”或“SDK”或“Helper 类”或我的听众很好理解的类似术语要么不准确，要么不正确似乎没有充分描述这个概念。

关于什么是一个好的替代术语的任何建议？

更新：我最近一直在阅读有关 MVVM + 控制器（MVVMC 或 MVCVM）的内容，并开始认为我们的一些应用程序服务操作可能真的可以被视为控制器。不过，我仍然不清楚验证（即 IDataErrorInfo）实现在这个世界中如何工作 -所有业务逻辑和验证是否都由“控制器”处理，可能引发类似于（或实际上相同）INotifyPropertyChanged 的​​事件.PropertyChanged？

洋葱架构和领域驱动设计中是否允许以下​​良好设计和允许？

说你有一个像这样的“订单”域类

拥有基础设施的领域模型调用接口是好还是坏的设计？（在这种情况下，notificationservice 和 CartRepository）

任何人都可以使用依赖反转来解释洋葱架构和分层架构之间的区别吗？在我看来，它们完全一样。非常感谢任何输入:)

这是我第一次实施更受领域驱动的设计方法。我决定尝试洋葱架构，因为它专注于域而不是基础设施/平台/等。

为了从实体框架中抽象出来，我创建了一个具有工作单元实现的通用存储库。

和IRepository<T>接口IUnitOfWork：

IRepository<T>和的实体框架实现IUnitOfWork：

客户存储库：

使用存储库的 ASP.NET MVC 控制器：

统一的依赖注入：

解决方案：

问题？

• 存储库实现（EF 代码）非常通用。这一切都在EntityFrameworkRepository<T>课堂上。具体模型存储库不包含任何此类逻辑。这使我免于编写大量冗余代码，但可能会牺牲灵活性？

• ICustomerRepository和CustomerRepository类基本上是空的。它们纯粹是为了提供抽象。据我了解，这符合 Onion 架构的愿景，在这种架构中，基础设施和平台相关代码位于系统外部，但空类和空接口感觉不对？

• 要使用不同的持久性实现（例如 Azure 表存储），则CustomerRepository需要创建一个新类并继承一个AzureTableStorageRepository<T>. 但这可能会导致冗余代码（多个 CustomerRepositories）？这将如何影响嘲笑？

• 另一种实现（例如 Azure 表存储）对跨国支持有限制，因此 AzureTableStorageUnitOfWork 类在这种情况下不起作用。

我这样做的方式还有其他问题吗？

（我的大部分灵感来自这篇文章）

我正在对 .NET 客户端服务器应用程序进行大规模现代化改造。我打算应用“洋葱架构”，因为我觉得它与未来架构尚未最终确定的现代化方法相匹配。

任何人使用 Onion Architecture 进行遗留现代化改造，您的意见都会有所帮助。