1. Слой сервисов — отдельный оъект. Тут не от нас зависит — в виде, котором вернет внешний сервис, не удобный для нас.
2. Слой данных — этот же объект чуть иначе представлен. Так же СУБД не все поддерживает, упрощает для нее.
3. Слой Domain — уже идеальное представление для нас.
4. Ну и само отображение на форме.
Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.
А если еще и окажется что поле потребует создать вложенный тип — то
Но это только одна из причин, почему современная разработка выедает любой бюджет и любое время — похоже на черную дыру.
А ведь еще есть — управление зависимостями с пресловутым адом зависимостей
Еще есть мода везде тянуть по 100500 внешних библиотек. Ну ОК, 150 штук в среднем на небольшой, не считая вложенных. И у каждой либы свои баги, у каждой свои особенности. Иногда они конфликтуют. Каждое обновление может разушить гармонию.
Еще — развертывание. Сейчас же принято на каждую функцию делать отдельный микросервис и все это управляется Kubernetes. А еще 6 платформ нужно поддерживать практически всегда.
В общем, пришли к какому-то Вавилону в конце концов
Здравствуйте, Shmj, Вы писали:
S>Для затравки: https://habr.com/ru/articles/903426/
S>Вот сейчас как принято:
S>1. Слой сервисов — отдельный оъект. Тут не от нас зависит — в виде, котором вернет внешний сервис, не удобный для нас. S>2. Слой данных — этот же объект чуть иначе представлен. Так же СУБД не все поддерживает, упрощает для нее. S>3. Слой Domain — уже идеальное представление для нас. S>4. Ну и само отображение на форме.
S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.
Программировании существует два вида проблем(сокращенно):
1. Сесть и написать код, т.е. это не проблема Это все кроме Domain и сервисов
2. Это собственно проблема. Это то что находится в Domain и сервисах
Проблема в том, что у многих 1 и 2 это одно и тоже.
Т.е. код который решает проблему это собтсвенно сервисы и домен. Остальное это просто обслуга всего этого. На практике этот подход реально работает, только нужно уметь им пользоваться.
Про маппинг и конверторы. Вот во многих книгах первое про что пишут, так это про границы. Граница — самый простой архитектурный шаблон. Следовать ему не требует большого ума и средства, а эффект хороший. В конце концов лучше иметь много комков грязи разделенных границами, чем один большой.
S>1. Слой сервисов — отдельный оъект. Тут не от нас зависит — в виде, котором вернет внешний сервис, не удобный для нас. S>2. Слой данных — этот же объект чуть иначе представлен. Так же СУБД не все поддерживает, упрощает для нее. S>3. Слой Domain — уже идеальное представление для нас. S>4. Ну и само отображение на форме.
Обычно не столько много. А 2-3 вида одной и той же сущности. Но допустим...
S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.
Надо при этом помнить, что добавить поле — это какая-то бизнес ценность, то есть то, что принесет прибыль или снизит затраты. Ну тогда в чем вопрос: нужно добавить поле для +N денег — добавляем поле в каждый вид сущности, работа такая
Другой распространенный кейс — это когда надо добавить/изменить поле лишь в одном типе сущности. Например, для оптимизации нужно добавить столбец в БД. При альтернативном подходе ты бы тянул это (необходимое только лишь для БД) изменение сквозь всю свою систему. Еще пример: нужно отдавать доп. инфу на фронт через РЕСТ. Ты поменял лишь выходное энтити — и все. В противном случае ты бы это еще и в базу писал. Зачем?
На простых hello, world примерах да, городить энтити не надо, а вот когда у тебя в реальном мире начинают расходиться энтити в базе, в АПИшках (разных) на входе/выходе, в бизнес-логике и где-нибудь там еще... Вот тогда без разделения на слои и разные энтити будет больно (и кстати дорого).
Ну и также помним, что по сути энтити эти — это АПИ, интерфейс между слоями приложения. АПИ/интерфейс не меняется, если нужно что-то поправить внутри.
Так что альтернатива куда хуже...
Да, если у тебя сервис очень простой и максимально вероятно, что не будет меняться, ну можно сделать одну общую энтити и для РЕСТа на входе, и на выходуе, и в базу так класть, и внутри в бизнес-логике им же оперировать.
S>Но это только одна из причин, почему современная разработка выедает любой бюджет и любое время — похоже на черную дыру.
Альтернативные реализации встанут еще дороже.
S>Еще есть мода везде тянуть по 100500 внешних библиотек. Ну ОК, 150 штук в среднем на небольшой, не считая вложенных. И у каждой либы свои баги, у каждой свои особенности. Иногда они конфликтуют. Каждое обновление может разушить гармонию.
Среди модно-молодежников — возможно. Но остались еще и инженеры-разработчики, которые не делают в угоду моде/о чем на хабре написали/где звезд больше на ГХ, а сначала думают
S>Еще — развертывание. Сейчас же принято на каждую функцию делать отдельный микросервис и все это управляется Kubernetes.
Никто ж не заставляет. Где-то это уместно (в большинстве случаем в современной мейнстримовой разработке), где-то — нет. Выбирай сам исходя из контекста.
S>Еще — развертывание. Сейчас же принято на каждую функцию делать отдельный микросервис и все это управляется Kubernetes. А еще 6 платформ нужно поддерживать практически всегда.
В чем сложность поддержать 6 платформ? Ну надо бизнесу мобилку — делаешь BFF (backed for frontend) или GraphQL или что там еще. Ну а как? Бизнесу это надо, опять-таки, для получения прибыли. Ну работа такая, опять же
S>В общем, пришли к какому-то Вавилону в конце концов
В можно-молодежных стартапа — зачастую да. В целом — нет.
Здравствуйте, Shmj, Вы писали:
S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.
Знаешь что самое дорогое в разработке? Далеко не написание кода. А согласования, блин. То, что одну и туже сущность приходится размазывать несколько раз — это вообще полнейшая фигня. Современные языки практически мгновенно позволяют все это делать очень быстро. А вот изменить API устоявшееся — это полнейший писец по времени. Ибо за одну часть отвечает одна команда, за другую другая, пишут все на разных языках зачастую. И одним нужно одни поля, другим другие, одним удобно так, другим по другому. Плюс еще всякие приколы, когда одни могут делать что то и бюджет под них выделен, а другие занимаются на других совершенно проектах. И зачастую пока ты там ожидаешь пока что то там согласуешь, ты вообще нафик забываешь что там за проект, какие подъемные камни, почему ты оценивал именно в такое количество времени, плюс концепция поменялась, плюс куча руководства поменялась, плюс те, кто принимали решения, уволились нафик.
И вот на все эти согласования и тратится основной бюджет. А изменения в 4-х местах плюс конверторы, это тупо для ускорения процесса. Плюс в любом случае нет универсальных представлений данных, потому для одной задачи оптимально одно представление, для другой другое, отсюда и конверторы.
S>Еще — развертывание. Сейчас же принято на каждую функцию делать отдельный микросервис и все это управляется Kubernetes. А еще 6 платформ нужно поддерживать практически всегда.
И это не всегда проблема. Когда это все поддерживаешь ты — это все очень быстро и оперативно развертывается, как с нуля новый сервис. Веселее когда руководство начинает беспокоить секьюрность, и ради развертывания выделяют девопсов, только у них есть права что то делать с развертыванием. Но так как обычно там все настроено, то девопсам конкретно по твоему проекту заняться нечем, но у них таких проектов десяток. И очень бывает весело когда что то рушится, девопса тупо нет, он или в отпуске, или он занят другим горящим проектом. А сам ни фига сделать не можешь так как типо безопасность, не положено тебе такие доступы иметь. И то, что занимало ранее 5 минут, тянется на неделю с привлечением 10 человек высшего менеджмента для простейших вещей блин через заявки, согласования, совещания и т.д.
Разработка фигня по затратам. Не фигня, когда на каждого разработчика по 3 администратора которые скрывают от него бюрократию и всяческие маразмы на разных уровнях. Напишешь, полностью уложившись в сроки, ибо на этапе разработки никто не мешал. А далее там согласования на внедрения, выделения бюджетов, закупки оборудования и т.д идут зачастую на порядок больше времени чем сама разработка, плюс там до фига биг боссов задействовано в этих согласованиях. Вот узкое место!!!!!
Здравствуйте, Shmj, Вы писали:
S>Для затравки: https://habr.com/ru/articles/903426/
S>Вот сейчас как принято:
S>1. Слой сервисов — отдельный оъект. Тут не от нас зависит — в виде, котором вернет внешний сервис, не удобный для нас. S>2. Слой данных — этот же объект чуть иначе представлен. Так же СУБД не все поддерживает, упрощает для нее. S>3. Слой Domain — уже идеальное представление для нас. S>4. Ну и само отображение на форме.
S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин.
Самое важное разделение — отделение домена от инфраструктуры. Инфраструктурные слои поддерживают контракты. Входные слои (контроллеры) поддерживает контракт с клиентами приложения (API приложения). А выходные слои (адаптеры) поддерживают (инкапсулируют) API провайдеров, с которыми работают приложение.
Имея такое разделение по слоям очень легко отвечать разные вопросы: Какие изменения нужно сделать, если входной контракт или контракт провайдера поменяется? Как повлияет добавление/удаление поля из домена на входные и выходные контракты. Это сильно помогает как при оценке доработок, так и при самих доработках.
Изменений несколько, потому что одно изменение делается в домене, а остальные изменения — в контрактах. И это отличный повод задуматься про это поле в этом конкретном контракте — нужно ли это поле, в каком оно формате, как обеспечить совместимость и т.п. Как уже сказали, работа с контрактами намного сложнее написания самого кода, т.к. требует согласования людей. Изменение контрактов — боль.
Также разделение на слои позволяет выделить контракты внутри приложения — интерфейсы между доменом и инфрой. Это позволяет разделить приложения на относительно простые куски, а также легко решать много полезных задач. Например, изменять схему БД (это происходит намного чаще, чем замена БД, о которой часто говорят). Или добавить кэша к БД (или к сервисам). Ну и, конечно же, все эти мидлвари, логи, трейсы, метрики, рейт-лимитеры, предохранители и прочие штуки, которые прекрасно живут в инфра слое, на загрязняя важный доменный код
Так что исправление в нескольких местах совсем небольшая плата за большое количество преимуществ.
P.S. Не сразу заметил, что это раздел священные войны. Не стал бы расписывать
S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями).
Там, над чем я сейчас иногда работаю, чтобы "добавить одно поле", надо законфигурить его в xml-ке, и оно появится "во всех слоях". ЧЯНТД?
Не то, чтобы у нас совсем маленький бюджет, чтобы тратить его на усложненние перекладывания данных. Скорее нам есть на что его тратить еще, т.к. это специализированный CAD, и там уйма логики.
Здравствуйте, Slipstream, Вы писали:
S>Там, над чем я сейчас иногда работаю, чтобы "добавить одно поле", надо законфигурить его в xml-ке, и оно появится "во всех слоях". ЧЯНТД?
А чтобы добавить нестандартный виджет на форму — сколько нужно конфигурировать в XML?
S>В общем, пришли к какому-то Вавилону в конце концов
Проблема появилась вовсе не с появлением микросервисов. Она появилась сразу с появлением программирования. Писать простой и понятный код — это искусство, мало кто владеет им в совершенстве, полностью никто не владеет.
В коммерческой разработки клиент всегда хочет больше фич, и в программу новую фичу добавить проще чем например перестроить уже построенное здание. В итоге кодовая база разбухает, через какое-то время самому автору уже не так просто в ней разобраться, а люди увольняются, приходят новые. Еще для ускорения разработки надо как-то распаралелить процесс, чтоб несколько программистов работали параллельно над несколькими фичами. Поэтому придумываются разные техники борьбы со сложностью и введением новых уровней абстракции, это позволяет писать еще более сложный софт с бОльшим количеством зависимостей, и для для того чтобы справиться с ним, нужные еще более продвинутые техники борьбы со сложностью, а это позволяет писать еще более сложный софт. В итоге через несколько лет, любой успешный софт превращается во что-то жуткое. Ну и еще, у программистов всегда есть неприодолимое желание к обобщению классификации и абстракции. Мне кажется какого-либо эффективного способа борьбы с этим в коммерческой разработке пока не придумано.
Есть несколько шагов по достижению "простого кода":
1. Ты свой код через полгода можешь сходу прочитать и понять.
2. Ты свой код через 3 года можешь сходу прочитать и понять.
3. Сотрудники в команде твой код через полгода могут сходу прочитать и понять.
4. Сотрудники в команде твой код через 3 года могут сходу прочитать и понять.
5. Большинство программистов, которые читают твой код могут сходу прочитать и понять.
Здравствуйте, Shmj, Вы писали:
S>Итого — чтобы добавить одно поле — нужно сделать изменения в 4 местах + в конвертерах (которые преобразуют между слоями). Допустим 5 мин. на каждое изменение — уже 20 мин. S>А если еще и окажется что поле потребует создать вложенный тип — то S>А ведь еще есть — управление зависимостями с пресловутым адом зависимостей
, который по прежнему не решен. S>Еще есть мода везде тянуть по 100500 внешних библиотек. Ну ОК, 150 штук в среднем на небольшой, не считая вложенных. И у каждой либы свои баги, у каждой свои особенности. Иногда они конфликтуют. Каждое обновление может разушить гармонию. S>Еще — развертывание. Сейчас же принято на каждую функцию делать отдельный микросервис и все это управляется Kubernetes. А еще 6 платформ нужно поддерживать практически всегда. S>В общем, пришли к какому-то Вавилону в конце концов
Прикинь сколько работы на ровном месте, и иного народу задействовано, и все получают деньги, и руководителей и лидов всех мастей огромное количество. А потом эти же люди идут на хабр и пишут статьи как круто и них получилось, и молодые, которые хотят самовыражения, ведутся и начинают воспроизводить процесс.
И самое главное что всем этим можно заниматься вообще не решая никаких прикладных задач.
Здравствуйте, Vzhyk2, Вы писали:
V>Здравствуйте, Shmj, Вы писали:
V>Есть несколько шагов по достижению "простого кода": V>1. Ты свой код через полгода можешь сходу прочитать и понять. V>2. Ты свой код через 3 года можешь сходу прочитать и понять. V>3. Сотрудники в команде твой код через полгода могут сходу прочитать и понять. V>4. Сотрудники в команде твой код через 3 года могут сходу прочитать и понять. V>5. Большинство программистов, которые читают твой код могут сходу прочитать и понять.
Вот реальный случай про код. В одном месте у меня была win-служба которая работала внешним сервисом. Начальник давно хотел сделать "универсальную" службу, я противился, но все таки сделал. В конфиге прописываются хранимки которые нужно вызывать, url куда нужно отправлять, тайм-ауты и т.д. Сделал, поставили, вроде все ок. Месяца через полтора обнаружили какие-то проблемы, так ни я не он не помнят как вообще это вещь работает, я глядя на код, вообще ни чего не мог сказать, мне пришлось поднимать переписку, что бы понять, что изначально требовалось, а потом все это воспроизводить у себя, подключаясь к внешнему сервису и это, что бы только разобраться как она работает, а уже потом я устронял проблему.
Здравствуйте, gandjustas, Вы писали:
G>Прикинь сколько работы на ровном месте, и иного народу задействовано, и все получают деньги, и руководителей и лидов всех мастей огромное количество. А потом эти же люди идут на хабр и пишут статьи как круто и них получилось, и молодые, которые хотят самовыражения, ведутся и начинают воспроизводить процесс.
Вы так говорите, как будто IT чем-то уникально и в других сферах жизнедеятельности человека — все обстоит иначе.
Вот взять юриспруденцию, законотворчество — там дела еще хуже
Эталоном считается медицина, мол врач реально работает и не может прокрастинировать, если назначена операция. Но и тут не так все просто — эти фарм. компании чего стоят. Да и сама суть медицины — цель не чтобы люди не болели, не профилактика — а цель именно дорогостоящее лечение.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Прикинь сколько работы на ровном месте, и иного народу задействовано, и все получают деньги, и руководителей и лидов всех мастей огромное количество. А потом эти же люди идут на хабр и пишут статьи как круто и них получилось, и молодые, которые хотят самовыражения, ведутся и начинают воспроизводить процесс.
S>Вы так говорите, как будто IT чем-то уникально и в других сферах жизнедеятельности человека — все обстоит иначе.
S>Вот взять юриспруденцию, законотворчество — там дела еще хуже
S>Эталоном считается медицина, мол врач реально работает и не может прокрастинировать, если назначена операция. Но и тут не так все просто — эти фарм. компании чего стоят. Да и сама суть медицины — цель не чтобы люди не болели, не профилактика — а цель именно дорогостоящее лечение.
IT действительно уникально. Что-то общее с другими сферами начинается где-то на уровне бизнеса, а не разработки.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Прикинь сколько работы на ровном месте, и иного народу задействовано, и все получают деньги, и руководителей и лидов всех мастей огромное количество. А потом эти же люди идут на хабр и пишут статьи как круто и них получилось, и молодые, которые хотят самовыражения, ведутся и начинают воспроизводить процесс.
S>Вы так говорите, как будто IT чем-то уникально и в других сферах жизнедеятельности человека — все обстоит иначе.
неявные сговоры конечно существуют и в других областях. Но мы в Ит работаем и видим сколько бабла улетает в трубу.
S>Вот взять юриспруденцию, законотворчество — там дела еще хуже
+\- также, одни юристы пишут толстые документы за деньги, а другие юристы их за большие деньги читают и проверяют. Но у юристов есть "источник правды" — суд. В ИТ такого нет. Любая архитектура хороша если ты досточно красиво о ней рассказываешь.
S>Эталоном считается медицина, мол врач реально работает и не может прокрастинировать, если назначена операция. Но и тут не так все просто — эти фарм. компании чего стоят. Да и сама суть медицины — цель не чтобы люди не болели, не профилактика — а цель именно дорогостоящее лечение.
Тут немного другое. Фарма просто покупает врачей, это коррупциорнная схема, сами врачи ни явно, ни неявно никак между собой не сговариваются.
Здравствуйте, gandjustas, Вы писали:
G>Любая архитектура хороша если ты досточно красиво о ней рассказываешь.
Кому рассказываешь? Пользователям? Им это не интересно
Бизнесу же часто все равно, что внутри. Ему важны только цена и сроки (t2m)
Правильнее перефразировать: любая архитектура хороша если она работает (т.е. позволяет достигать целей).
Особенно верно в хайлоад, где часто не подходят стандартные архитектуры
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, gandjustas, Вы писали:
G>>Любая архитектура хороша если ты досточно красиво о ней рассказываешь.
Б>Кому рассказываешь?
Лицам принимающим решения
Б>Бизнесу же часто все равно, что внутри. Ему важны только цена и сроки (t2m)
Именно, поэтому бизнесу и рассказывают про важность микросервисов, ООП и какой-то там еще архитектуры.
Сравнить то не с чем.
Б>Правильнее перефразировать: любая архитектура хороша если она работает (т.е. позволяет достигать целей).
Тогда никакой границы сверху у тебя нет. После вложения достаточного количества денег любая архитектура работает.
Б>Особенно верно в хайлоад, где часто не подходят стандартные архитектуры
До хайлоада еще надо дожить, а у большинства проектов микросервисов больше чем пользователей и разработчиков вместе взятых.
Здравствуйте, Qulac, Вы писали:
Q>так ни я не он не помнят как вообще это вещь работает, я глядя на код, вообще ни чего не мог сказать, мне пришлось поднимать переписку, что бы понять, что изначально требовалось, а потом все это воспроизводить у себя, подключаясь к внешнему сервису и это, что бы только разобраться как она работает, а уже потом я устронял проблему.
Вот, ты тогда не достиг Дао.
Здравствуйте, Vzhyk2, Вы писали:
V>Здравствуйте, Qulac, Вы писали:
Q>>так ни я не он не помнят как вообще это вещь работает, я глядя на код, вообще ни чего не мог сказать, мне пришлось поднимать переписку, что бы понять, что изначально требовалось, а потом все это воспроизводить у себя, подключаясь к внешнему сервису и это, что бы только разобраться как она работает, а уже потом я устронял проблему. V>Вот, ты тогда не достиг Дао.
Дао, тут заключается в том, что решение которое казалось универсальным и хорошим(не мне только), на практике оказалось совсем не удобным.
Здравствуйте, Qulac, Вы писали:
Q>Дао, тут заключается в том, что решение которое казалось универсальным и хорошим(не мне только), на практике оказалось совсем не удобным.
Речь о том, что такое "пиши простой код", а не о чем-то вашем, личном.
