我正在尝试将六边形架构应用于一个项目，该项目将有多个应用程序必须处理相同的域模型。
例如，我们将有一个请求应用程序服务的 mvc 网站，然后该服务将处理域模型和数据访问层。到目前为止一切都很好。
我的问题是什么时候应该实例化一个应用程序服务类。我应该为所有用户（单例）只拥有任何类的一个实例吗？或者我应该为每个用户实例化一个，然后让它保存一些用户数据并存储在用户会话中？或者我应该为每个请求实例化一个新类？
当然，这些选项中的任何一个都是可能的，但我想获得您的最佳实践建议。
我猜这个类越无状态越好，但是无状态类意味着我需要通过每个我不特别喜欢的方法调用来传递用户特定的数据。
我通常将我的服务和持久性类保持在请求范围内。这有助于确保如果出现问题并且我不会留下部分数据，我可以恢复数据事务。
至于为什么您不想要更持久的事务范围，这通常是提高性能的一种非常糟糕的方法，并且可能导致意外行为。特别是当涉及依赖瞬态或作用域类的单例时。因为由于单例被创建一次，它的依赖关系被创建一次。这对于非线程安全的类来说是非常危险的。更多关于范围的信息。
至于您对传入用户数据的担忧。我会将您关心的所有信息放在某种用户数据帮助器界面后面。让您的服务依赖它而不是传递该数据。然后您可以创建一个特定于您要支持的客户端的用户数据助手。您可以使用依赖注入来配置您的 mvc 应用程序以使用该用户数据帮助程序的 mvc 特定实现。你架构中的其他客户端也可以做同样的事情。
我将为用户信息帮助程序编写一个自定义界面，以满足您现有服务的需求。自定义实现可以基于会话数据或您的客户可以提供的任何内容。也就是说，实现可能依赖于现有的库，但会将这些数据转换为通用格式供您的服务层使用。这样你就可以在不破坏应用程序的其余部分的情况下交换你的用户信息在帮助程序中来自哪里。