Viktor Ilukhin, в целом идеи верные, но тут на целый флейм тянет. В DDD просто нет прямой завязки на базу данных и операций над данными. Есть сущности домена и операции над сущностями домена, описывающие их цикл
В принципе про разбиение на микросервисы могу много чего подсказать. На общественных началах, конечно. Так что если ничего секретного то можем отдельно поговорить голосом позже. Контакты есть)
Viktor Ilukhin, действия с сущностью нужно выполнять только те, которые предусматриваются процессами, а идентификаторы в рамках доменной модели, если память не изменяет, не существуют. Есть связи. Сервис не является сущностью домена, даже если он абстрактный. Сервис это способ взаимодействия с доменом. Доменная модель как бы и существует для того чтобы отделить данные от процессов, а так же создать ось координат (если упростить)
Антон Р., если тянешься то потом придется выбирать процентное соотношение и чем хочется больше заниматься) например, Solution это больше pre-sales и бизнес, system это больше настроек и кодинга, но и с съёмного администрирования
v_k, тогда нужно смотреть key-value storage. если тысяч 10 в день то просто поставить хороший ssd и RAID для надежности. выдержит. Redis подойдет, но я за облака
Иван, если ты сейчас про горизонтальное масштабирование SQL решений то партиции себя в своей архитектуре плохо показали уже) есть только одно решение из SQL, которое мне действительно нравится в масштабировании, но оно есть только в AWS и это Aurora
Артем, разнести на разные сервисы. Если вы храните все на одном сервере то про безопасность можно забыть, а если все в разных местах то успехов даже достаточно опытным ребятам. Модно почитать как данная история устроена архитектурно у AWS KMS. Они отлично придумали и интегрировали с AWS S3. Правда, если вы в РФ то бросаться туда хранить персональные данные не советую. А если они не персональные то там все вместе решается) а доступ к файлам решается одноразовыми ссылками там же
