gRPC and Domain Driven Design - Where to place proto files (domain layer vs elsewhere)?

Question

I am running into an issue with proper architecture when using gRPC. In a traditional DDD approach, the core project (i.e. innermost layer / domain layer) has no references to the outside layer and only really contains entities/aggregates/interfaces/value objects and so on. Actual implementation of these might go in separate layers (infrastructure/application/etc.)

With gRPC, the contract (i.e. the interface) is defined at the proto file level. But these proto files have to be compiled as server/clients in order to work. From my intro to DDD, the core layer should not really have package references (e.g. in .Net core, I am using a .Netstandard 2.1 project for my core domain project - it has no external nuget package references and is kept clean). In a normal scenario, you could build an interface specific to your domain layer for things like marker interfaces etc. in order to avoid polluting your domain layer with external dependencies. But with proto files, that is not possible.

There are three options I can choose:

• Place proto files in core project, add necessary packages in core project to compile them
• Place proto files in core project, but build them in another project (i.e. when building project, get a relative reference to the file in another project and build them)
• Utilize a shared project that has all these proto files and build them there

I am wondering what the correct approach to this is. I can see pros and cons for all but would like some information on if one approach is better than others.

Justiciary

Answer 1

You should not put proto file into Domain. Domain must include only Business logic and not other stuff.

If we talk about layers - proto files, first of all, are description of your communication. In other words, presentation layer (API) is the good place for them.

About additional packaged in Domain - you can do this, but you should minimize them.

Charge

Regarding packages in domain - yup but I try and minimize it via marker interfaces if possible. But regarding the proto files, does this apply if the only contents are messages? I understand that file themselves communicate intent as its specific to tooling but trying to think about it from the other side. – Justiciary

I think your argument makes sense. It is after all a communication method so it does not belong in the domain layer. I'll go with the application layer as it serves the same purpose as a controller but I might move the files (just message proto files) to a class library if I end up having too many bounded contexts to manage – Justiciary

Answer 2

Short answer. I think Domain Layer is not the best place for proto files. I would place them into Infrastructure Layer.

Long answer. To answer your question lets refer to Eric Evans's book.

1. According to the book there are 4 application layers: UI Layer, Application Layer, Domain Layer, Infractructure Layer.

   UI Layer - Responsible for showing information to the user and interpreting the user's commands.

   Domain Layer - Responsible for representing concepts of the business, information about the business situation, and business rules.

   Infrastructure Layer - Layer Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain etc.

2. Another phrase from the book:

   Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code.

According to points above proto files are more closer to Infractructure Layer. But bear in mind sometimes exclusions are possible. For example when your application is performance sensitive, putting proto files into business layer may be a good trade off.

Acorn

Answer 3

They should be in their own sharable module.
In this way you can import them within your service in order to build the implementation service, and share with your clients in order for them to build their client (so that they import just the contract they need).

Gomer

Yup I decided on this and what I'll end up doing in the future - for now I just went to the application layer as I only had a single BC which has a grpc service and i didn't want to include another project. – Justiciary