Понатыкают анемиков по всему проекту и считают что они пошли в ФП

Ребят, день добрый!
Может кто-нибудь сталкивался с задачей выбора оптимального on premise файлового хранилища?

Есть проект, требуется распределенное файловое хранилище для большого объема данных - от 10 Тб общего объема, файлы размером от 10кб до 1гб, с поддержкой реплик, гарантией записи, в идеале ещё с шардированием из-под коробки.

Не могу взять облачные решения, так как требуется развернуть все это на инфраструктуре заказчика.

Нашел решение - min.io, вроде по всем параметрам подходит. Может есть ещё какие-то варианты?

Что-нибудь можете сказать про использование монги (grid fs)? Ещё видел некий ceph, но показался оверкиллом.

ну тут опять же нужны конкретные примеры. во всяком случае я не готов какие-то общие правила формулировать

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

Мне вот нравится пример - допустим у нас есть стандартная регистрация пользователя с верификацией email-а (потому что на email будут приходить важные вещи и нам важно что бы пользователь не ввел херню - ему же хуже).

В этом случае мы можем создать некий агрегат который будет хранить в себе неподтвержденный email  (UnconfirmedEmail какой, я так себе в нэйминг) и после подтверждения ты можешь использовать этот агрегат что бы сделать какого-нибудь Customer.

В этом случае вся валидация прекондишенов для создания Customer будет происходить в рамках UnconfirmedEmail и причин кастомеру ругаться на email не будет. Так же как и причин по которым ты где-то еще захочешь сделать какого-то другого кастомера с таким же набором ограничений на входящие данные.

Пример может так себе конечно, но смысл в этом. Скрыть информацию о отдельном этапе жизни данных от всей остальной системы. Кастомеру теперь об этом знать не надо. И всем кто работает с кастомером тоже...

Всё равно хотя в каком то аггрегате будет проверка на пустую строку и бросание исключения в конструкторе для email

проверки будут но не обязательно в конструкторе

проверки будут но не обязательно в конструкторе

Всё равно хотя в каком то аггрегате будет проверка на пустую строку и бросание исключения в конструкторе для email

а почему исключение а не сообщение?

напр new NotEmptyString('email@test.xy');

а почему исключение а не сообщение?

вот опять же, если есть возможность явно типами задавать переходы стэйта и связывать это с функциями - это в целом не сильно отличается по смыслу от классов и агрегатов

главное informathin hiding а способов достигнуть этого в целом не мало (или мало... но они есть)

если есть возможность и у тебя код написан руками. то не важно какими конкретно паттерными и подходами ты пользуешься.

Типа (string) => NotEmptyString|Error?

"хочешь хорошо делай хорошо". Отличное и оч полезное замечание

а когда у тебя в проекте "тру-ФП" с мутабельными анемиками и процедурками запихнутыми в статически методы, то это не оч