Как читать и писать с использованием CQS

Question

Я собираюсь начать новый проект с CQS (как один из аспектов его дизайна), но без CQRS + Event Sourcing, или Streaming, или Historical Modeling. Когда я сталкиваюсь с ситуацией, в которой у меня будет большой набор людей, использующих небольшой набор данных (и не желающих блокировать пользователя), я буду реализовывать Event Sourcing. То, что это значит (по крайней мере для меня), - это все, что я делаю, начиная с отделения команды от запроса (разделения интересов).

Я использую EF ORM и фактическую схему для командной стороны. Что касается запросов, лучше всего использовать только представления (из того, что я читаю), но это мнение, я думаю, не мешает мне использовать ORM (или нет), и / или Repo, или ADO.NET + хранимые процедуры, и т.д., как метод доступа к этим представлениям из БД (я думаю).

Вот диаграмма, которую я сделал, чтобы приблизительно проиллюстрировать то, что я имею в виду (она ни в коем случае не является всеобъемлющей):

Мой вопрос:

Часть 1: я не знаю - правильно / лучше / проще всего / наиболее оптимизировано / наиболее легко обслуживаемо / проще всего перейти на источник событий в какой-то момент (я понимаю, что это субъективно) для получения данных из базы данных (из a) и использовать ViewModels (DTO), чтобы предоставить клиенту новый вид некоторого состояния (ПОСЛЕ вызова на командной стороне)?

Часть 2: После того, как я внес изменение в веб-интерфейс на основе задач и, следовательно, изменил ViewModel, который лежит в основе пользовательского интерфейса, как мне выполнить команду из этого, когда ViewModel полностью отделен от Entities (Domain Model) на командной стороне?, Эти ViewModels (DTO) могут иметь совершенно другую "форму", чем сущности.

ОБНОВЛЕНИЕ:

Чтобы было ясно, я не собираюсь использовать Async, и транзакции являются плюсом для запуска, это только разделение команд и запросов (не полноценный CQRS, где командная сторона возвращает только "void") - я ищу самые основы здесь. Кроме того, из того, что я читал до сих пор, кажется, что DDD и ограниченный контекст идут рука об руку с CQRS, на данный момент я не имею никакого реального опыта работы с DDD или Aggregate Root вместе с ограниченным контекстом и до сих пор не видел реальная и насущная необходимость задействовать эту методологию / шаблон. В данный момент кажется, что я буду использовать EF/Migrations для командной стороны и не решил, что использовать на стороне запроса (рассматривается ADO.NET).

Командная сторона в моем случае вернет объект, например, нового Клиента с базой данных, сгенерированной CustomerId. Я буду использовать одну базу данных как для команд, так и для запросов, и хотел бы использовать сборку Views в БД для возврата моделей из запросов (другими словами, я бы хотел, чтобы запросы были "отображены" в представлениях по большей части), Чего я не знаю, так это как должна выглядеть команда в тех случаях, когда и объект должен быть возвращен, если я должен использовать сторону запроса для возврата данных для стороны команды. Я постараюсь включить Automapper для преобразования объектов в ViewModels в случае MVC.

Answer 1

Я должен признать, что мне трудно найти актуальный вопрос здесь, но я буду использовать название в качестве основы для моего ответа.

Прежде всего вы заявляете, что не собираетесь использовать CQRS, но предлагаемое вами решение очень близко к архитектуре CQRS, в большей степени, чем что-либо еще. Быть новичком и пробовать шаблон, но в то же время вносить в него значительные изменения, добавляет высокую степень сложности.

В основном, для того, чтобы успешно читать и писать с использованием CQS, важно, чтобы вызывающая сторона контролировала генерацию идентификаторов. Это позволяет сохранить объект, а затем извлечь его без необходимости полагаться на командную операцию, возвращающую значения. Гиды являются отличными кандидатами на это.

Также я должен заявить, что существуют очень большие различия между CQS и CQRS как шаблонами. CQS - это шаблон низкого уровня, который можно применять практически в любой архитектуре, а CQRS - шаблон очень высокого уровня. Они разделяют философию дизайна, но не намного больше.