我一直在努力理解这种新的架构，其名称可以是洋葱架构，清洁架构，端口和适配器等。
如果我采用端口和适配器的抽象，当我为特定端口调整我的应用程序时，我可以从我的应用程序内部给端口一个实体吗？或者我总是应该调整实体，以适应端口？
示例：
说我有一个客户实体。我有一个使用我的应用程序的UI。我的UI通过适配器调用getCustomerById（123）。反过来，我的适配器将调用我的应用程序，使用注入的存储库有效地检索客户，它将对其执行某种格式化和日志记录，而不是，一旦客户准备好，它就会返回到我的UI。我的问题是，我的Customer对象按原样返回给我的UI。这意味着我的UI从我的Core项目中引用了Customer类。然后我的UI继续使用该Customer对象执行操作，可能更改其名称等，并最终再次调用适配器以更新客户端（客户）。
这样做可以吗？我的UI在我的应用程序核心内部使用Customer类是否可以。或者我是否应该将我的客户调整为一个新的Customer对象，比如说UICustomer并让我的UI工作，在客户端和UICustomer之间在适配器级别来回映射？
答案 0 :(得分：1)
我也开始学习/实施洋葱架构。据我所知，您的原始方法（UI中的客户实体）是一种可接受的做法。在这里查看洋葱架构的图形化线性表示：
http://jeffreypalermo.com/blog/the-onion-architecture-part-3/
您可以看到UI可以直接与底层对象模型交互。由于您的客户不是直接的数据库实体，而是从注入的存储库加载，这似乎符合洋葱的模型。
我的假设是客户实体实际上是由注入的存储库组装的不同的，规范化的数据库实体的组合。
我的理解是，原则上，交互是通过抽象来完成的，而客户实体是客户数据库的抽象表示，这是有效的。
如果上述任何假设/想法不正确，请纠正我。
答案 1 :(得分：1)
好问题。我有一个可能有用的例子。 https://bitbucket.org/jeffreypalermo/onion-architecture
对于使用Core域模型对象的简单应用程序，可以很好。它们的设计目的是没有令人讨厌的依赖性触角，因此它们工作得非常好并且非常便携。他们可以穿越各层而不会造成任何问题。