gRPC和领域驱动的设计-在哪里放置proto文件(域层与其他地方)？
在使用gRPC时，我遇到了一个关于适当架构的问题。在传统的DDD方法中，核心项目(即最内部的层/域层)没有对外部层的引用，只包含实体/聚合/接口/值对象等等。这些应用程序的实际实现可能在单独的层(基础设施/应用程序/等等)中进行。
使用gRPC，契约(即接口)是在proto文件级别定义的。但是，为了工作，这些proto文件必须编译为服务器/客户端。从我的介绍到DDD，核心层不应该真正有包引用(例如，在.Net内核中，我使用.Netstandard 2.1项目作为我的核心域项目--它没有外部nuget包引用，并且保持干净)。在正常情况下，您可以为诸如标记接口等事情构建特定于您的域层的接口，以避免外部依赖关系对域层造成污染。但是对于proto文件来说，这是不可能的。
我可以选择三种选择：
- 将proto文件放置在核心项目中，在核心项目中添加必要的包以编译核心项目中的
- 位置proto文件，但在另一个项目中构建它们(即在构建项目时，获取对另一个项目中文件的相对引用并生成它们)
- 利用拥有所有这些proto文件的共享项目并在那里构建它们。
我想知道正确的方法是什么。我能看到所有人的优点和缺点，但我想了解一种方法是否比其他方法更好。
回答 3
Stack Overflow用户
发布于 2020-06-24 20:52:24
您不应该将proto文件放入域。域必须只包括业务逻辑，而不包括其他内容。
如果我们谈论层-原始文件，首先，是对你的沟通的描述。换句话说，表示层(API)是它们的好地方。
关于域中的附加打包-您可以这样做，但您应该尽量减少它们。
Stack Overflow用户
发布于 2020-07-02 19:28:57
简短的答案。我认为域层不是最适合proto文件的地方。我会把它们放到基础设施层。
要回答你的问题，请参考艾瑞克·埃文斯的书。
- 根据本书有四个应用层: UI层、应用层、域层、结构层。
UI层-负责向用户显示信息并解释用户的命令。
域层-负责表示业务的概念、有关业务情况的信息和业务规则。
基础结构层-层提供支持更高层的通用技术功能:应用程序的消息发送、域的持久性等。
书中的另一个短语是
- ：
将与域模型相关的所有代码集中在一个层中，并将其与用户界面、应用程序和基础结构代码隔离开来。
根据以上各点，proto文件更接近于底层。但请记住，有时排除是可能的。例如，当应用程序对性能敏感时，将proto文件放入业务层可能是一个很好的折衷方法。
Stack Overflow用户
发布于 2020-07-02 17:23:24
它们应该在自己的共享模块中。
通过这种方式，您可以在服务中导入它们，以便构建实现服务，并与客户端共享，以便客户端构建客户端(以便他们只导入所需的合同)。
https://stackoverflow.com/questions/62563785
复制相似问题
腾讯云开发者
