Использование классов Protobuf vs с каркасом/слоем отображения в Java

Question

Я не мог найти «лучшие практики» в Интернете для использования gRPC и protobuf в рамках проекта. Я реализую приложение на стороне сервера, основанное на событиях. Ядро определяет агрегаты, события и службы домена без внешних зависимостей. Сервер gRPC вызывает основные службы, проходящие в объектах запроса, которые в конечном итоге переходят в публикуемые события. События сериализуются с использованием protobuf и публикуются на проводе. Мы в настоящее время в дилемму о том, следует ли наши события быть Protobuf генерироваться классы напрямую, или мы должны держать ядро ​​и события разделиться и реализовать картографа/сериализатора слой, чтобы перевести события между Protobuf < -> ядро ​​

Если есть другой подход, который мы не рассматриваем, пожалуйста, направляйте нас :)

Спасибо за помощь.

Answer 1

Protobufs действительно хороши для последовательной и обратной совместимости, но не настолько хороши в качестве объектов Java первого класса. Добавление пользовательских функций в protos в настоящее время невозможно. Вы можете получить много преимуществ при использовании Protobufs на поворотном слоя, завернуть их в одном из ваших событий Pojos, и передать их вокруг внутренне как таковой:

public final class Event { 
private final EventProto proto; 

public void foo() { 
    // do something with proto. 
} 
} 

Большинство проектов не меняют свой файл .proto что часто и почти никогда не обратным образом несовместимо (ни провод, ни API). Необходимость менять много кода из-за прото-изменений никогда не была проблемой в моем опыте.

Answer 2

Модель предметной области Объекты и Передача данных объектов (Protobuf сообщений) должны быть разделены как можно больше. Для этого лучше всего преобразовать объекты модели домена в сообщения Google Protobuf и наоборот. Мы сделали protobuf-converter, чтобы сделать его чрезвычайно простым.