SP
Да, шаблон - это адрес который может сохранить пользователь, чтобы потом заного не вводить, а заполнить поля 1 кликом
вопрос - что будет если поменять адрес в "шаблоне". Ответ на этот вопрос должен дать тебе подсказку
Size: a a a
2020 December 16
ПГ
вопрос - что будет если поменять адрес в "шаблоне". Ответ на этот вопрос должен дать тебе подсказку
Это понятно, что даже с вариантом булевого поля, это разные строки в таблице.
ПГ
Что шаблон и адрес должны меняться независимо друг от друга
SP
Добрый день. А что делать с даннвми, которые появятся после создания агрегата? Например, создаем Company ($name, $inn, $postAddress) - каталог компаний. У каждой Company есть набор услуг Services (надо, конечно, придумать другое название), которые потом должны заполняться пользователем. Отдельно от Company услуги существовать не могут, бессмысленно, но на момент создания Company, мы еще не знаем какие услуги будут. Делать так Company ($name, $inn, $postAddres, ?Services $services = null) или при создании Company в хендлере создавать еще и отдельную сущность Services с company_id с пустыми значениями? $company = new Company (
$id = ID::next(), ...); $this->repository->add($company); $services =new Services ($id)?
$id = ID::next(), ...); $this->repository->add($company); $services =new Services ($id)?
а зачем агрегату компании список сервисов? У этого агрегата есть какие-то инварианты которые на это завязаны? Не делаешь ли ты слишком жирные агрегаты?
Обычно эти связи нужны только для UI. По факту же можно просто айдишку компании сервису передать и тогда все живет отдельно друг от дружки.
Ну и еще - многие инварианты не являются инвариантами которые прям нужно соблюдать "immediate".
Обычно эти связи нужны только для UI. По факту же можно просто айдишку компании сервису передать и тогда все живет отдельно друг от дружки.
Ну и еще - многие инварианты не являются инвариантами которые прям нужно соблюдать "immediate".
ПГ
а зачем агрегату компании список сервисов? У этого агрегата есть какие-то инварианты которые на это завязаны? Не делаешь ли ты слишком жирные агрегаты?
Обычно эти связи нужны только для UI. По факту же можно просто айдишку компании сервису передать и тогда все живет отдельно друг от дружки.
Ну и еще - многие инварианты не являются инвариантами которые прям нужно соблюдать "immediate".
Обычно эти связи нужны только для UI. По факту же можно просто айдишку компании сервису передать и тогда все живет отдельно друг от дружки.
Ну и еще - многие инварианты не являются инвариантами которые прям нужно соблюдать "immediate".
А если есть какие либо инварианты на количество сервисов или "качество" сервисов внутри агрегата. Тогда связи все же делать или выносить в отдельный "сервис" все эти проверки и подсчеты?
П
никак?) Ну то есть, в чем подход то? кто файлики сервит? Есть какой "изоморфный JS" где и бэк и фронт один и тот же код юзают, и есть "обычный"... но что-то мне подсказывает что твой вопрос про другое
Есть реакт клиент. Он может работать сам по себе на каком нибудь своём сервере и использовать бэк как источник данных. Либо его можно держать в том же сервере где и бэк, и бэк будет отдавать его индекс. Пытаюсь понять как щзагуглить, чтобы сравнить подходы
MG
Павел
Есть реакт клиент. Он может работать сам по себе на каком нибудь своём сервере и использовать бэк как источник данных. Либо его можно держать в том же сервере где и бэк, и бэк будет отдавать его индекс. Пытаюсь понять как щзагуглить, чтобы сравнить подходы
Если разные места - нужно брать во внимание коммуникацию между ними, если на одном - то такой проблемы нет. Во всяком случае больше сходу не могу придумать разницы между 2 сервера и 1 сервер. Подходы для гугления тут вряд-ли можно найти, это не подходы, ты просто ложишь что-то куда-то потому-то
AD
Павел
Есть реакт клиент. Он может работать сам по себе на каком нибудь своём сервере и использовать бэк как источник данных. Либо его можно держать в том же сервере где и бэк, и бэк будет отдавать его индекс. Пытаюсь понять как щзагуглить, чтобы сравнить подходы
они должны вместе менятся и масштабироватся?
П
они должны вместе менятся и масштабироватся?
Пока неизвестно
П
Тогда другой вопрос - сервер должен проверять на секьюрность Index.html?
П
Тоесть
1. Сервер всегда отдает индекс, а клиент первым делом запрашивает залогиненого юзера, и получает его либо ошибку 403
2. Сервер сам проверяет сразу юзера, и либо отдает индекс либо логин страницу
1. Сервер всегда отдает индекс, а клиент первым делом запрашивает залогиненого юзера, и получает его либо ошибку 403
2. Сервер сам проверяет сразу юзера, и либо отдает индекс либо логин страницу
MG
Какая вообще разница? Делай как удобно/ как можешь/ как получается. Второй вариант выглядит предпочтительнее, меньше лишней работы
П
Какая вообще разница? Делай как удобно/ как можешь/ как получается. Второй вариант выглядит предпочтительнее, меньше лишней работы
Ну если внимательно подумать, то можно понять что во втором варианте сервер делает дофига того что ему не нужно.
П
В первом он является лишь источником данных
MG
Ну так в чём суть вопроса?
П
В том как народ делает и что я могу не предусмотреть
П
В секьюрности
MG
Ну, можно зайти дальше и проверять пользователя на уровне веб-сервера, и отдавать 403 даже не дойдя до клиента или до бекенда
П
Вот я про это и говорю
П
Как то криво выглядит