Ну например его нужно перенести согласно id созданной сущности, сжать, повернуть и т.д

Генерируем id заранее (UUID например) и решаем очень много проблем

Ну например его нужно перенести согласно id созданной сущности, сжать, повернуть и т.д

так а причем тут модел то?

Для сущностей тоже

Для сущностей тоже

да, uuid хорошо решают кучу проблем

но не сильвер булет)

p.s. штуки вроде ресайза и генерации превьюшек я больше люблю налету делать (штуки вроде imaginary)

А что в нашем мире сильвер булет? ))

А что в нашем мире сильвер булет? ))

серебрянная пуля это серебрянная пуля. Ваш кэп

p.s. штуки вроде ресайза и генерации превьюшек я больше люблю налету делать (штуки вроде imaginary)

Ну да не причем) Ступил)

Я к тому что нет ни одного метода / паттерна / подхода который был бы "сильвер булет". Всему есть валидные и нет кейсы. UUID в том числе.

Ваш кэп (С) Sergey Protko

Ооо

накину

есть у меня проектик

и в нем есть такая сущность как User

так получилось что юзается эта сущность по всему проекту. И если в двух третях я могу заменить ее например на UserID то... короч что меня смушает

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

я хотел бы вынести аутентификацию и все что связано с доступом в отдельную сущность Credentials

то есть для аутентификации у меня будет агрегат состоять из двух сущностей - Credentials и User.

корнем будут креды. Если мы при логине что-то путное сделаем - сможем юзера попросить прокачать скил.

я пока здраво рассуждаю или не очень?

прокачать скил - что это значит?

короч пока для меня загадка - как создать этот агрегат. Я про процесс регистрации

А зачем выносить аутентификацию в отдельную сущность? Плодить сущности, относящиеся к одному юзеру как-то не очень, мне кажется

прокачать скил - что это значит?

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

А зачем выносить аутентификацию в отдельную сущность? Плодить сущности, относящиеся к одному юзеру как-то не очень, мне кажется

20 публичных методов в одном классе как-то тоже

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

ну и да мне уже реально мешает

ну и на других проектах я так делал и мне было удобно. Что меня смущает - процесс регистрации

20 публичных методов в одном классе как-то тоже

Паттерн Фасад

я плохо представляю как мне "зарегать" чувака

Имхо, все связанное с аторизацией / аутентификацией должно быть таки в User. А вот "управление профилем", "прокачать скилл" в каком нить Account

Паттерн Фасад

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

Для регистрации / логина юзаем Saga которая и будет создавать обе сущности

Имхо, все связанное с аторизацией / аутентификацией должно быть таки в User. А вот "управление профилем", "прокачать скилл" в каком нить Account

окей, давай переименуем) есть User и есть Account

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

https://ruseller.com/lessons.php?rub=37&id=2149

https://ruseller.com/lessons.php?rub=37&id=2149

вот когда ты мне пояснишь к чему тут фасады - тогда поговорим

вот когда ты мне пояснишь к чему тут фасады - тогда поговорим

К разделению

Но сохранению одной сущности

окей, давай переименуем) есть User и есть Account

Я к тому что может стоит выносить не Credentials, а именно Acount / Profile

Я к тому что может стоит выносить не Credentials, а именно Acount / Profile

хорошо, кто будет роль хранить?

конкретика - есть у пользователей "бэджи" в зависимости от которых они могут логиниться туда или туда. И в зависимости от них по трети системы проверки идут всякие

хотя... блин

User т.к. роль оно к аутентификации, нет?

User т.к. роль оно к аутентификации, нет?

ну тогда мне повсюду нужны будут и User и Account

хотя честно сказать Account нужен будет только для перентационного слоя

то есть можно dto собрать из них обоих

ладно, пойду попробую порефакторить

Но сохранению одной сущности

зачем мне сохранять одну сущность то?)

Почему повсюду? Как по мне тут четкое деление на: 1. User - авторизация, роли 2. Account - профиль, скилл (уровень, или как там еще)

ну в целом да, так и есть...

И да по сути роль у User может быть привязана к скилу у Account. Для этого есть Saga...

зачем мне сохранять одну сущность то?)

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

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

не решит фасад моей проблемы

не решит фасад моей проблемы

Как хочешь

проблема у меня простая - слишком жирный класс который изменяют по двум совершенно разным причинам

фасад как правило немного по другому работает. Конкретно то что ты предлагаешь - это адаптер

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

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

У тебя разве не в этом проблема?

Тебе надо отделить аутентификацию, отдели в другой класс, но собери фасадом в общем

У тебя разве не в этом проблема?

повторюсь. Если у тебя есть "одна штука" с одним интерфейсом и ты закрываешь ее "другим интерфейсом" - это не фасад, это адаптер.

Тебе надо отделить аутентификацию, отдели в другой класс, но собери фасадом в общем

мне не надо ничего собирать

это разные штуки которые по случайности попали в один класс

Ладно, может я тебя не до конца понял, что тебе надо, уже за полночь

да, надо идти кодить

)

А что в нашем мире сильвер булет? ))

TDD

TDD

нет

TDD

Нет

знаю людей для которых больше DbC подходит например. А еще есть вещи которые через tdd на юнит тестах именно и не сделаешь вовсе.

(тогда в дело вступают atdd, bdd и прочие штуки)

нет

что хорошо тестируется то как правило обладает лучшим дизайном, если допустим на uml что то разобрал и допустил ошибку к примеру, а тесты сопротивляются то значит что то не так

ну и еще есть армия фанатов property based testing

что хорошо тестируется то как правило обладает лучшим дизайном, если допустим на uml что то разобрал и допустил ошибку к примеру, а тесты сопротивляются то значит что то не так

тесты надо уметь писать и практика покзывает что писать их умеют не все

и уж тем более слишком много людей концентрируют внимание именно на составляющей тестов нежели на том как тесты влияют на дизайн кода

https://t.me/tdd_ru

заходи)

а, ты там уже есть...

а, ты там уже есть...

??

Всем Привет!

привет)

привет

Привет)

Привет

Привет

шалом

Привет

Привет

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

привет

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

почитай по event storming

https://blog.redelastic.com/corporate-arts-crafts-modelling-reactive-systems-with-event-storming-73c6236f5dd7