значит неверно сформулировал :)

напомните плз, как называются правила, которым должны соответствовать предусловия (LSP)

сами по себе предусловия и есть правила.

или ты про предикаты?

Инвариант

ну инварианты это инварианты (предикаты, описывающие валидное состояние) а предусловия это предусловия (предикаты, описывающие валидные входные значения)

контракты?

да, предусловия, постусловия и инварианты формируют контракт

и называется все это логикой Хоара

ну инварианты это инварианты (предикаты, описывающие валидное состояние) а предусловия это предусловия (предикаты, описывающие валидные входные значения)

если описаны валидные входные значения, мы же в итоге получаем валидное состояние?

если описаны валидные входные значения, мы же в итоге получаем валидное состояние?

если валидность этого состояния зависит только от входных значений

если валидность этого состояния зависит только от входных значений

а нормально ли в конструкторе проверять входные данные и выбрасывать исключения в случае неуспешности?

а нормально ли в конструкторе проверять входные данные и выбрасывать исключения в случае неуспешности?

да, нормально

мм, а если у нас объект с данными без поведения, я так понимаю это DTO. А должен ли тот кто работает с этим DTO проверять его на валидность или он должен доверять тем данным, которые находятся в этом DTO?

Мне кажется DTO подразумевает какую-никакую валидацию

мм, а если у нас объект с данными без поведения, я так понимаю это DTO. А должен ли тот кто работает с этим DTO проверять его на валидность или он должен доверять тем данным, которые находятся в этом DTO?

Как тебе удобнее) Но чем ближе валидация к самой логики обработки этих данных (действиям над этими данными), тем лучше

Как тебе удобнее) Но чем ближе валидация к самой логики обработки этих данных (действиям над этими данными), тем лучше

ну вот например у меня есть SmsMessage{from, to, message} и SmsSender с методом send(SmsMessage sms). Где проверять валидность телефона to, в DTO SmsMessage при создании или уже при отправке send?

PhoneNumber to :)

ну вот например у меня есть SmsMessage{from, to, message} и SmsSender с методом send(SmsMessage sms). Где проверять валидность телефона to, в DTO SmsMessage при создании или уже при отправке send?

я бы сделал Value object - PhoneNumber и валидировал внутри. Но есть несколько правил валидации: бизнес-правила (телефон может быть только определенных стран) и валидация типа длина телефона не меньше 9 символов.

PhoneNumber to :)

мы так далеко пойдем) SmsMessage{ PhoneNumber from, PhoneNumber to, Message message} ?))

мы так далеко пойдем) SmsMessage{ PhoneNumber from, PhoneNumber to, Message message} ?))

именно :)

мы так далеко пойдем) SmsMessage{ PhoneNumber from, PhoneNumber to, Message message} ?))

А что тут такого?)

тогда валидация происходит внутри VO PhoneNumber?

тогда валидация происходит внутри VO PhoneNumber?

ес

Можете поправить, если не прав. Хочу понять разницу между OOA (object-oriented analysis) и OOD (obj.-orin. design). OOA - это процесс\методология, в которой разработчики общаются со стакхолдерами, собирают информацию о проекте, определяют классы и объекты, группируют их по контексту, определяют как объекты контактируют друг с другом, определяют каким поведением объекты владеют и какие данные должны содержать. Рисуются диаграмы с целью упростить понимание системы и коммуникацию между бизнессом и девелоперами. OOD - это процесс, когда ставятся\определяются ограничения в виде технологий (язык, фреймворк, бд и т.д.), ожидаемой нагрузки, масштабируемости, бюджета и времени. Далее, это ограничения реализуются с использованием выбранных технологий и учетом поставленных ограничений. Могут использоваться более "технические" диаграммы.

мм, а если у нас объект с данными без поведения, я так понимаю это DTO. А должен ли тот кто работает с этим DTO проверять его на валидность или он должен доверять тем данным, которые находятся в этом DTO?

не все объекты с данными и без поведения DTO.

Можете поправить, если не прав. Хочу понять разницу между OOA (object-oriented analysis) и OOD (obj.-orin. design). OOA - это процесс\методология, в которой разработчики общаются со стакхолдерами, собирают информацию о проекте, определяют классы и объекты, группируют их по контексту, определяют как объекты контактируют друг с другом, определяют каким поведением объекты владеют и какие данные должны содержать. Рисуются диаграмы с целью упростить понимание системы и коммуникацию между бизнессом и девелоперами. OOD - это процесс, когда ставятся\определяются ограничения в виде технологий (язык, фреймворк, бд и т.д.), ожидаемой нагрузки, масштабируемости, бюджета и времени. Далее, это ограничения реализуются с использованием выбранных технологий и учетом поставленных ограничений. Могут использоваться более "технические" диаграммы.

можно просто убрать OO из этих аббривиатур и получится "анализ требований" (не путать с бизнес анализом) и "дизайн"

из ооп тоже можно убрать ОО

хуйню скинул

можно просто убрать OO из этих аббривиатур и получится "анализ требований" (не путать с бизнес анализом) и "дизайн"

а чем БА отличается от анализа требований?

нашел, спасибо))

а чем БА отличается от анализа требований?

БА - разобраться с проблемой и придумать решение, по сути конвертация проблем в требования. Просто занятный факт что бизнес никогда требования не генерит, он генерит воркараунды котторые смог придумать имея то что имея.

БА - разобраться с проблемой и придумать решение, по сути конвертация проблем в требования. Просто занятный факт что бизнес никогда требования не генерит, он генерит воркараунды котторые смог придумать имея то что имея.

Т.е., примерно такой флоу - BA -> OOA -> OOD

какие по твоему артефакты у OOA?

UML диаграмма компонентов?)

классов?)

диаграмма юзкейсов?

короч я думаю что это просто можно убрать

какие по твоему артефакты у OOA?

По-моему все то, что ты перечислил) Но я соглашусь, что это скорее анализ требований, определение проблем и возможных путей их решения. Далее выбор самого подходящего пути решения и реализация на этапе оод. Ну вот если бы тебя на собесе спросили, в чем разница между ООА и ООД?

вот пишут, что в репозиториях не должно быть методов сохранения — только добавление и удаление, а сохранение [«списка»] реализуется через unitOfWork. а кто занимается сохранением конкретных DO? вот я вытащил из репозитория объект, поменял в нём какое-то поле (где-нибудь в Application layer). А дальше? кому принято отдавать этот объект, чтобы он скормил его мапперу и положил его в ORM? (объект при этом не ActiveRecord)

вот пишут, что в репозиториях не должно быть методов сохранения — только добавление и удаление, а сохранение [«списка»] реализуется через unitOfWork. а кто занимается сохранением конкретных DO? вот я вытащил из репозитория объект, поменял в нём какое-то поле (где-нибудь в Application layer). А дальше? кому принято отдавать этот объект, чтобы он скормил его мапперу и положил его в ORM? (объект при этом не ActiveRecord)

флаш делать после того как закончен юз кейс. Если АР, то я просто создаю метод save и не парюсь. Если загоняться сильно, то утонешь в «архитектуре»

вот пишут, что в репозиториях не должно быть методов сохранения — только добавление и удаление, а сохранение [«списка»] реализуется через unitOfWork. а кто занимается сохранением конкретных DO? вот я вытащил из репозитория объект, поменял в нём какое-то поле (где-нибудь в Application layer). А дальше? кому принято отдавать этот объект, чтобы он скормил его мапперу и положил его в ORM? (объект при этом не ActiveRecord)

Флаш в контролёре после отработки юзкейса

По-моему все то, что ты перечислил) Но я соглашусь, что это скорее анализ требований, определение проблем и возможных путей их решения. Далее выбор самого подходящего пути решения и реализация на этапе оод. Ну вот если бы тебя на собесе спросили, в чем разница между ООА и ООД?

я не перечислял конкретных артефактов

вот пишут, что в репозиториях не должно быть методов сохранения — только добавление и удаление, а сохранение [«списка»] реализуется через unitOfWork. а кто занимается сохранением конкретных DO? вот я вытащил из репозитория объект, поменял в нём какое-то поле (где-нибудь в Application layer). А дальше? кому принято отдавать этот объект, чтобы он скормил его мапперу и положил его в ORM? (объект при этом не ActiveRecord)

у тебя есть unit of work (или нет)

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

ну мол.... я не очень уверен в том что unit of work вообще штука нужная...

у тебя есть unit of work (или нет)

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

одно я знаю точно - универсальный UoW это не оч хорошая идея

м… а если UoW не нужен, то методы обновления DO «можно» класть в репозиторий? и это не будет дурно пахнуть?

м… а если UoW не нужен, то методы обновления DO «можно» класть в репозиторий? и это не будет дурно пахнуть?

https://www.slideshare.net/Yaboomaster1/save-repository-from-save

ну save в репозитории не такая уж и плохая идея если у тебя все грамотно на агрегаты разбито)

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

а вот тут пишут, что плохо https://programmingwithmosh.com/entity-framework/common-mistakes-with-the-repository-pattern/ Save/Update method in repositories но там говорят про UoW

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

просто нет смысла пихать это в репозиторий)

сделайте отдельную штуку для этого

понятно что не сам репозиторий будет это делать и что у меня там под копотом будет какой-то UoW. просто я бы не хотел деталь реализации репозитория экспоузить наружу

а потому у меня был бы метод в репе типа.. void commit() { uow.commit() }

ведь именно это ты сделаешь, добавив в него commit/save

сложный вопрос

в идеале можно еще так сделать... repoOrUowNotSure.transactional(repo => { // logical transaction goes here })

короч меня оч напрягают решения которые включают в себя отдельный глобальны UoW

типа того что ты можешь в доктрине увидеть например

или в Hibernate

в идеале можно еще так сделать... repoOrUowNotSure.transactional(repo => { // logical transaction goes here })

типа такого, только ж скорее и будет youOrm.unit(uow => { … })

сделайте отдельную штуку для этого

презентацию не грузит а как назвать такую штуку? сейчас у меня в репозитории есть метод save(DO) в который передаю DO, он там маппится в модель и оборачивается в uow отдаётся в ORM Но насколько это красиво?

типа такого, только ж скорее и будет youOrm.unit(uow => { … })

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

ну и вообще есть мысль что все это от лукавого и надо делать replace

или еще как...

с Марко поговори на эту тему)

делай евенты и не парься

ну вот Марко топит на ES на хаскеле)

rx там или mostjs

благодарю и там тоже про UoW пишут…

типа такого, только ж скорее и будет youOrm.unit(uow => { … })

я к тому что в целом UoW нужен для агрегата.

я к тому что в целом UoW нужен для агрегата.

ну в целом да

ну мол... идея UoW в том что бы контролить и персистить стэйт агрегата в границах транзакции логической. То есть существование UoW вне репозитория в целом не имеет смысла

коммит транзакции не в репозитории ж

так же как нет смысла в UoW если у тебя агрегат в база хранится в табличке вида CREATE TABLE my_cool_aggregates ( id uuid NOT NULL PRIMARY KEY, state jsonb NOT NULL )

ну даже тут есть смысл

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

которые совсем не доменные

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

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

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

не уверен на счет один uow на один аггрегат

а в каком месте принято проверять уровни доступа? ну чтобы, например, юзер не менял чужие проекты подменой id. в обработчике api вызовов? в сервисе? в репозитории?

а в каком месте принято проверять уровни доступа? ну чтобы, например, юзер не менял чужие проекты подменой id. в обработчике api вызовов? в сервисе? в репозитории?

it depends. В целом подобные проверки на запись удобно выносить в какие либо сервисы (погугли spring security voters). На чтение - проще всего просто на уровне доступа к данными отфильтровывать вещи которые тебе нельзя смотреть (если возможно)

p.s. ты там свой велосипед/фреймворк не изобретаешь часом?

p.s. ты там свой велосипед/фреймворк не изобретаешь часом?

не, я велосипедизмом [пока ещё] не страдаю. просто пытаюсь придать форму ~400кб кода во время лепки возникают странные необходимости из серии «дёрнуть объект из слоя хранилища из уровня приложения». тогда я понимаю, что где-то что-то не так и возникают странные вопросы. (например, пару дней мучался мешая в репозитории объекты домена с моделью базы, а потом мне сказали, что нужны в этом месте сервисы — и наступило немного счастья)

слои это лож

А как правильно сделать и куда вынести, приходят с поиска данные по сортировке, пишу на yii2, так вот в зависимости от данных меняется сортировка в запросе и соответственно desc asc, данные меняется селектом, сортировать по городу или по району(для примера) при чем сортировка по разным колонкам. Где и как грамотно указывать что сортировка должна быть здесь а определение какую колонку использовать уже в другом месте ?

сейчас у меня рак, для себя писал