DDD отлично подходит в качестве подхода при разработке вашего CRM.Я использовал его в своем последнем проекте (веб-CRM), и это было именно то, что мне нужно.На самом деле, если бы я не использовал DDD, было бы невозможно управлять.CRM, который я создал (единственный архитектор и разработчик), был очень сложным и очень индивидуальным.Он интегрируется со многими внешними системами (т. Е. С сервером электронной почты и системой телефонных звонков).
Первое, что вы должны сделать, это обнаружить основные части вашей системы.Это самая сложная часть, и вы, вероятно, ошибаетесь с первого раза.Хорошая вещь заключается в том, что это итеративный процесс, который должен стабилизироваться до того, как он попадет в производство, потому что тогда его сложнее подвергнуть рефакторингу (т. Е. Вам нужно перенести данные, а это болезненно).Эти основные части называются ограниченными контекстами (BC) в DDD.
Для каждого БК я создал модуль.Мне не нужны были микросервисы, модульный монолит был просто идеален.Я использовал Закон Конвея , чтобы обнаружить БК.Я заметил, что у каждого отдела были общие, но и разные потребности от CRM.
Были некоторые общие BC, которые были общими для каждого отдела, такие как получение / отправка электронной почты, запись активности клиентов, планирование задач, уведомления.Поведение было практически одинаковым для всех отделов.
Базы, относящиеся к конкретным отделам, имели очень разное поведение для сходных понятий.Например, отдел продаж и отдел обработки данных предъявляли разные требования к контракту, поэтому я создал два агрегата с именем Contract, которые имели один и тот же идентификатор, но у них было другое поведение «данные +».Чтобы держать их "синхронизированными", я использовал Saga / Process Manager.Например, когда контракт был активирован (вручную или после первого платежа), тогда был создан DataProcessingDocument, содержащий данные, основанные на содержании контракта.
Еще одна важная точка зрения заключается в обнаружении и уважении источниковистиныНапример, источником правды для полученных писем является сервер электронной почты.CRM должен отражать это в своем пользовательском интерфейсе, должно быть очень ясно, что это только отсроченное отражение того, что происходит на сервере электронной почты;могут быть получены электронные письма, которые не показаны в CRM по техническим причинам.
Источником правды для черновиков электронных писем является CRM с модулем Email composer.Если черновик больше не отображается, то это означает, что он был удален пользователем CRM.
Когда CRM не является источником правды, тогда код должен иметь небольшое поведение или вообще не иметь его, а данные должны быть в основномнеизменный.Здесь у вас может быть CRUD, если только у вас нет проблем с производительностью (т.е. миллионов записей), и в этом случае вы можете использовать CQRS.
И в каждой таблице может быть много записей (+ 100 000 строк), поэтому выбор индексов будет весьма важен, а транзакции присутствуют повсеместно, потому что будет много одновременного доступа к записям данных.
CQRS очень помог мне иметь исполнителя +отзывчивая система.Вам не нужно использовать его для каждого модуля, только если у вас много данных и / или различное поведение для записи и чтения.Например, для записи активности с клиентами я использовал CQRS, чтобы иметь списки исполнителей (поэтому я использовал CQRS из соображений производительности).
Я также использовал CQRS, где у меня было много разных представлений / проекций/ интерпретации одних и тех же событий.
Обязательно ли нам нужно работать с множеством баз данных, и должно ли это быть обязательно mongoDb, nosql?Я могу себе представить, что ответ - нет, но могу я попросить рассказать немного подробнее?Или перенаправьте меня на статьи, которые дадут мне достаточно четкий ответ
Конечно, нет.Используйте все, что работает.Я использовал MongoDB в 95% случаев, а Mysql только для модуля поиска.Управлять только системой баз данных было проще, а производительность / масштабируемость / доступность были достаточно хорошими.
Надеюсь, эти мысли помогут вам.Удачи!