почему?

ну если создадут ИП с 12 цифрами, а потом поменяют на 10цифровое ИНН, то чтото будет не так, верно?

мне кажется ты слишком много в VO пытаешься запихнуть

именно

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

Тоесть единое целое которое не может существовать даже без одной его составной части? А например пост в бложике - может быть VO? Т.е. пост не может существовать без тайтла, боди и времени создания например

Тоесть единое целое которое не может существовать даже без одной его составной части? А например пост в бложике - может быть VO? Т.е. пост не может существовать без тайтла, боди и времени создания например

валюта может существовать отдельно от VO которая представляет некую сумму денег

суть VO в том что оно имутабельное, хочешь новое значение - сделай новое VO

В целом чем меньше у тебя мутабельных сущностей - тем бОльшая предсказуемость кода

Тоесть единое целое которое не может существовать даже без одной его составной части? А например пост в бложике - может быть VO? Т.е. пост не может существовать без тайтла, боди и времени создания например

У поста есть id

и два VO равны только если стэйт этих VO одинаковый

Т.е для VO надо писать свой VO::equals(VO $another): bool

да

тип того

или у тебя язык умеет сравнение по значению)

но лучше конечно методом

многого хочу от VO... я ж хотел простую валидацию. VO - Age например наверняка провалидирует цифровое значение возраста. чтобы сильно отрицательным не былг например

а слегка отрицательным быть может?)

ну эт от домена зависит :)

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

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

но это мы отвлеклись. ладно

Парни, помогите по полкам разложить: Есть сущность, хранящаяся не нескольких системах Есть модель в коде, описывающая эту сущность и несколько сервисов, загружающие сущность из систем. Далее задача: загрузить одну и ту же сущность из разных систем и "смержить" различающиеся поля по определенной логике. И тут возникает вопрос: где должна быть логика этого мержа?

Парни, помогите по полкам разложить: Есть сущность, хранящаяся не нескольких системах Есть модель в коде, описывающая эту сущность и несколько сервисов, загружающие сущность из систем. Далее задача: загрузить одну и ту же сущность из разных систем и "смержить" различающиеся поля по определенной логике. И тут возникает вопрос: где должна быть логика этого мержа?

мне кажется что "сущность" хранящаяяся на нескольких системах это странно

сущность в виде гномика, судя по всему

семь параллельных красных линий...

это юзер

имеет место быть рассинхронизация данных между системами, поэтому именно такая постановка

всеравно непонятно

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

в отдельный сервис базы данных

ну фактически да. Но на уровне кода это одна модель (DO)

этот слой, если я правильно понял, адаптеры к внешним системам и репозиторий, возвращающий модель.

сейчас так и есть - отдельный сервис, запрашивающий внешние системы и получающий из трёх объектов User четвертый такой же с "корректными" полями. Но что-то мне не нравится.

А смущает меня наверное то, что в сущности помимо сквозного id есть еще system1Id, system2Id, system3Id. Не нужно ли сделать отдельные модели и развести их наследованием?

и иметь общий стейт в родителе?

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

но я пока не знаю, хорошо это или нет

А вообще KISS

KISS - факт :)

ну фактически да. Но на уровне кода это одна модель (DO)

ну значит никаких вопросов у тебя нет)

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

шарить данные между подсистемами так себе идея

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

и ты связи не видишь?

ERROR: S client not available

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

и что можно было бы подругому сделать что бы не пришлось вообще шарить данные и потом их мерджить

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

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

Напоминает шутку про конкурирующие стандарты

Если вам надо переносить дублирующиеся данные в одну систему, то переносите, а не дублируйте их в новую систему:)

да я уже понял, что по существу вопроса я получу ответ только когда его сформулирую нормально

а для антирасистов есть такое?)

Напиши классическое «ненавижу расизм и негров»

https://www.youtube.com/watch?v=2iYdKQXGY2E

https://www.youtube.com/watch?v=2iYdKQXGY2E

tldr есть? насколько понял - чисто на послушать и подумать о высоком

tldr есть? насколько понял - чисто на послушать и подумать о высоком

вот же ленивые... это ж Уди. - размышления на тему того, как софт меняет бизнес - советы о том, как объяснить бизнесу что софт который вы пишите для них это не проект а продукт (про различия так же) - мысль о том что переписать проект никогда не проще/дешевле чем отрефакторить существующий. И что "тут проще переписать" никогда не мотивируется здравым смыслом а скорее от безысходности. - интересная мысль что на поддержку любят садить джунов, хотя все понимают что баги фиксить и фичи пилить проще когда проект разрабатывается. То есть типа почему-то логично на более сложный вариант посадить джуна, который сделает все хуже, а на более простой посадить синьера. - О том как строить переговоры с бизнесом, типичные проблемы с ролями (например то что аналитик есть но у него нет обычно такого влияния что бы спорить с бизнесом, который на самом деле не требования нам приходит, а воркараунды к своим проблема, не самые эффективные часто), и о том как это все сосуществует с agile/lean/итеративными моделями - Опять о том что decoupling при помощи слоев это слишком наивная идея, и что резать приложение надо не только по горизонтали но и по вертикали, позволяя выстраивать каждую "вертикаль" функционала хоть со своей архитектурой. Если смотрел microservices, rules engine то там про то же

Начиная с "проще переписать" резко не согласен

уфф, спасибо, я ожидал буквально одно предложение :)

Начиная с "проще переписать" резко не согласен

в любом правиле есть исключения, прежде чем "не соглашасться" посмотри плиз видос. НЕнавижу людей которые делают какие-то выводы по tldw/tldr

А я в корне не согласен

Не в деталях

аргументируй

А я в корне не согласен

1. у тебя есть опыт работы с приложением которому лет 5? 2. у тебя есть опыт "переписать с нуля" приложение которому лет 5 и которым пользуются, на которое завязан бизнес?

3. объем приложения и степень важности оного. Сроки.

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