В DDD доменый уровень является самым нижним и ни от чего не зависит. В database-centric доменый уровень рамазан по таблицам и коду с бизнес-логикой их изменения. Круглое в квадратное не вставляется.
В DDD модель ничего не знает ни о каких БД. Это для неё внешний источник, откуда брать инфу и куда её грузить. Через репозиторий. Если удобно, то где-то в репозитории используется AR, чтобы упростить взаимнодействие с базой.
Если же используется database-centric, то бизнес модель — это таблица в базе данных. И там принципы DDD не применимы от слова совсем.
Так сравнение версий исходного кода не поможет, так как бинарники или минифицированные версии могут быть немного не тем, что получается из исходников. А любовь к использованию готовых сборок идет ещё со времен jQuery.
На криентсайде хорошей практикой между вьюхой и риквестом будет иметь слой, который билдит структуру запроса. Это позволяет иметь довольно простой меппинг между полем и его местом в запросе.
Т. е. при описании поля в довольно простой форме описываем путь его получения. Билдер запроса всё остальное сделаем сам.
От статьи создается впечатление, что проблема там была не с микросервисами, а как поддерживать 100500 версий сервиса. Для поддержки — это, конечно, ад. Решение было в области отказа от старых версий.
Можно ли было это сделать, оставаясь в микросервисах? Наверное, да. Вопрос только в том, какую логику обновления сервисов задействовать после изменения в общих зависимостях? Автосборка всех зависимых сервисов? Отказ от деплоя или частичный деплой только прошедших тесты, сервисов? И т.д.
Больше вопрос в том, покрываем ли мы тестами все случаи запрошенной бизнес-логики, когда реализуем её через умную функцию. Или отделываемся парой основных бизнес-кейсов, а остальные случаи проверять не будем, так как функция эта слишком умная и вариантов флоу в ней могут быть десятки, а бизнес просит только о двух.
А по факту перед нами может и всё правильно делающая функция, но не тестируемая из-за своей архитектуры. Переход на TDD, как раз, позволяет уйти от сложных и умных архитектур, как потенциально не тестируемых. Хотя без тестов они могут выглядеть очень даже красиво. Тесты позволяют видеть за этой красотой уязвимые участки кода и места совмещение функционала.
единственный тест может покрыть все code paths, если на верхнем уровне этот code path один, а все подуровни уже покрыты тестами/правильность гарантирована системой типов.
Так тест покрывает только верхний уровень, т.е. логику выполнения самой функции, а не её внутренностей.
Это контракт: если на входе это, то на выходе должно быть то.
И простота данной схемы сразу выявляется функции, которые, вроде бы, не сильно параметризированы, но внутренняя логика зависит от состояния объектов, которые в неё поданы. И либо писать на каждое состояние объектов и их пересечение свой контракт (а нам все равно это надо делать, хотя бы разбираясь с тем, какая для каждого случая будет бизнес-логика), либо переписывать.
Плюсы. Зачем нужен child process и как его готовить у меня представление есть. Про Worker API совсем ничего не читал. Хочется чуть более подробного введения, для чего и как его использовать, и в чем его преимущество над уже существующими решениями.
Тесты пишут не для того, чтобы застраховаться от изменений. Тест — это, в первую очередь, контракт, выполнение которого проверяется.
Когда код покрыт тестами, то любая доработка естественным образом мигрирует на TDD, так как сначала все равно нужно формализовать изменения контрактов.
Потому что в противном случае приходится держать контракт в голове, пока правишь под него код.
Как раз-таки имеет. Написание теста на такую функцию сразу выявит, что конвертация XML в специальный класс — это одна задача, а манипуляция этим классом — другая. И проверять этот функционал проще, когда он разнесен по разным функциям, чем писать каскад тестов на всевозможные пересечения.
можно и функцию на 1000 строк написать без потери читаемости.
Тут проблема будет не с читаемостью, а с переиспользованием переменных в рамках одной области видимости. Так что лучше разбить на логические изолированные куски и оформить в самостоятельные функции. И логика работы функции будет выражена намного яснее метаязыком названий внутренних функций.
Если же говорить о чисто «багфиксинге», то все сводится к попаданию кода в продакшен-ветку. После чего она собирается, артефакт кладется в деплой-репу. Все, кто мониторят деплой-репу, обновляются. Продакшен, стейдж, что угодно — просто разные ветки.
В другом комментарии уже написал, что контейнер со старым кодом можно и не глушить. Изолировать его каким-нибудь образом, чтобы новые запросы на него не шли, спокойно синхронизировать его том и вернуть в пул.
Либо пойти ещё дальше и делать сине-зеленый деплой.
Ревью кода настолько обобщенная вещь, что его единственная цель — это решать ту задачу, ради которой оно было введено.
Если оно введено для галочки и отлично эту галочку закрывает — то так тому и быть.
Если введено для того, чтобы никто не мог реализовать свои индивидуальные порывы по улучшению продакшена, и ты теперь знаешь, что твои «улучшения» дальше твоего рабочего места не уйдут — то быть такому ревью.
Чтобы перекрыть кислород расторопным менеджерам, умело подбивающих разработчиков пропихнуть в рамках других задачи их личные хотелки — почему нет?
Если в команде два с половиной человека, и ревью — это отличная возможность для них обмениваться знаниями и опытом в подходах к решению поставленных перед ними задач — что в этом плохого?
Плохим ревью становится только тогда, когда превращается в необходимый ритуал (понажимать на кнопки, написать дежурные фразы), и те, кто этим занимаются, не могут объяснить, зачем лично им оно нужно.
Да, для чего бы ни использовался какой-угодно инструмент, ретроспективно всегда можно указать, что это не самое лучшее применение. Но если это что-то живое (а не зацементированный ритуал), то оно будет со временем эволюционировать вместе с задачами, которые необходимо будет решать. И пока есть осознание, что если мы этот инструмент уберем, то старая проблема вернется, — мы все делаем правильно.
В принципе, контейнеры можно и не убивать. Нужна система изоляции, позволяющая исключать апстримы. После чего на том контейнера накатывается rsync и он возвращается в строй. С одним сервисом на машину нам бы пришлось изолировать её целиком. Контейнерами мы же можем упаковать железку каким угодно способом.
Но преимущество докера не в максимальном использовании машины, а в снятии с разработки инфраструктурных ограничений в виде языков, версий, библиотек.
MDK реально хорош для натива. Но, в том числе из-за того что это всё-таки фреймворк исполнения, мне ближе и интереснее докер-вей, как не вводящий очередные «рамки» в разработку.
Т.е. статика у вас будет выглядеть как у нас код, только без карт содержимого?
Вебпак и ко по сути ввели стандарт, что вся сборная статика выглядит в виде [name].[hash].[ext].
git-pull- и rsync- контейнеры
Это и есть способ доставки.
Гит-пулл — чтобы доставить до сервера код, который на нем будет крутится.
Rsync — чтобы снять слепок этого кода, таким образом сняв «блокировку» с гит-пулл-тома. php-fpm будет использовать тот же том, что и rsync-контейнер, в том время как гит-пулл контейнер спокойно может обновлять у себя код до новой версии, ни о чем более не думая.
Простой кейс, когда приходит новый коммит.
— гит-пулл-контейнер обновляет свой том до этого коммита;
— rsync-контейнер ищет неиспользуемый rsync-том (чтобы не с нуля) и синхронизирует в нем код с гит-пулл-тома;
— поднимается php-fpm-контейнер с этим синхронизированным томом;
— старый php-fpm-контейнер глушится, освобождая для повторного использования свой rsync-том.
Квадратура круга, раз уж мы о взаимозаменяемости говорим.
Не нужно мешать DDD и Database-centric подход.
В DDD модель ничего не знает ни о каких БД. Это для неё внешний источник, откуда брать инфу и куда её грузить. Через репозиторий. Если удобно, то где-то в репозитории используется AR, чтобы упростить взаимнодействие с базой.
Если же используется database-centric, то бизнес модель — это таблица в базе данных. И там принципы DDD не применимы от слова совсем.
Так сравнение версий исходного кода не поможет, так как бинарники или минифицированные версии могут быть немного не тем, что получается из исходников. А любовь к использованию готовых сборок идет ещё со времен jQuery.
https://jeffhandley.com/2018-09-13/graphql-is-not-odata
Годная статья с описанием преимуществ и недостатков. Но что самое важное, ясное и основное на опыте понимание архитектуры и методов использования обеих технологий.
На криентсайде хорошей практикой между вьюхой и риквестом будет иметь слой, который билдит структуру запроса. Это позволяет иметь довольно простой меппинг между полем и его местом в запросе.
Т. е. при описании поля в довольно простой форме описываем путь его получения. Билдер запроса всё остальное сделаем сам.
Это базовый шаблон для PHP
Можно ли было это сделать, оставаясь в микросервисах? Наверное, да. Вопрос только в том, какую логику обновления сервисов задействовать после изменения в общих зависимостях? Автосборка всех зависимых сервисов? Отказ от деплоя или частичный деплой только прошедших тесты, сервисов? И т.д.
А по факту перед нами может и всё правильно делающая функция, но не тестируемая из-за своей архитектуры. Переход на TDD, как раз, позволяет уйти от сложных и умных архитектур, как потенциально не тестируемых. Хотя без тестов они могут выглядеть очень даже красиво. Тесты позволяют видеть за этой красотой уязвимые участки кода и места совмещение функционала.
Так тест покрывает только верхний уровень, т.е. логику выполнения самой функции, а не её внутренностей.
Это контракт: если на входе это, то на выходе должно быть то.
И простота данной схемы сразу выявляется функции, которые, вроде бы, не сильно параметризированы, но внутренняя логика зависит от состояния объектов, которые в неё поданы. И либо писать на каждое состояние объектов и их пересечение свой контракт (а нам все равно это надо делать, хотя бы разбираясь с тем, какая для каждого случая будет бизнес-логика), либо переписывать.
А в чем принципиальное отличие от child process api?
Когда код покрыт тестами, то любая доработка естественным образом мигрирует на TDD, так как сначала все равно нужно формализовать изменения контрактов.
Потому что в противном случае приходится держать контракт в голове, пока правишь под него код.
Тут проблема будет не с читаемостью, а с переиспользованием переменных в рамках одной области видимости. Так что лучше разбить на логические изолированные куски и оформить в самостоятельные функции. И логика работы функции будет выражена намного яснее метаязыком названий внутренних функций.
Если же говорить о чисто «багфиксинге», то все сводится к попаданию кода в продакшен-ветку. После чего она собирается, артефакт кладется в деплой-репу. Все, кто мониторят деплой-репу, обновляются. Продакшен, стейдж, что угодно — просто разные ветки.
В другом комментарии уже написал, что контейнер со старым кодом можно и не глушить. Изолировать его каким-нибудь образом, чтобы новые запросы на него не шли, спокойно синхронизировать его том и вернуть в пул.
Либо пойти ещё дальше и делать сине-зеленый деплой.
Если оно введено для галочки и отлично эту галочку закрывает — то так тому и быть.
Если введено для того, чтобы никто не мог реализовать свои индивидуальные порывы по улучшению продакшена, и ты теперь знаешь, что твои «улучшения» дальше твоего рабочего места не уйдут — то быть такому ревью.
Чтобы перекрыть кислород расторопным менеджерам, умело подбивающих разработчиков пропихнуть в рамках других задачи их личные хотелки — почему нет?
Если в команде два с половиной человека, и ревью — это отличная возможность для них обмениваться знаниями и опытом в подходах к решению поставленных перед ними задач — что в этом плохого?
Плохим ревью становится только тогда, когда превращается в необходимый ритуал (понажимать на кнопки, написать дежурные фразы), и те, кто этим занимаются, не могут объяснить, зачем лично им оно нужно.
Да, для чего бы ни использовался какой-угодно инструмент, ретроспективно всегда можно указать, что это не самое лучшее применение. Но если это что-то живое (а не зацементированный ритуал), то оно будет со временем эволюционировать вместе с задачами, которые необходимо будет решать. И пока есть осознание, что если мы этот инструмент уберем, то старая проблема вернется, — мы все делаем правильно.
Далее всё сферическо-вакуумное.
В принципе, контейнеры можно и не убивать. Нужна система изоляции, позволяющая исключать апстримы. После чего на том контейнера накатывается rsync и он возвращается в строй. С одним сервисом на машину нам бы пришлось изолировать её целиком. Контейнерами мы же можем упаковать железку каким угодно способом.
Но преимущество докера не в максимальном использовании машины, а в снятии с разработки инфраструктурных ограничений в виде языков, версий, библиотек.
MDK реально хорош для натива. Но, в том числе из-за того что это всё-таки фреймворк исполнения, мне ближе и интереснее докер-вей, как не вводящий очередные «рамки» в разработку.
Вебпак и ко по сути ввели стандарт, что вся сборная статика выглядит в виде [name].[hash].[ext].
Это и есть способ доставки.
Гит-пулл — чтобы доставить до сервера код, который на нем будет крутится.
Rsync — чтобы снять слепок этого кода, таким образом сняв «блокировку» с гит-пулл-тома. php-fpm будет использовать тот же том, что и rsync-контейнер, в том время как гит-пулл контейнер спокойно может обновлять у себя код до новой версии, ни о чем более не думая.
Простой кейс, когда приходит новый коммит.
— гит-пулл-контейнер обновляет свой том до этого коммита;
— rsync-контейнер ищет неиспользуемый rsync-том (чтобы не с нуля) и синхронизирует в нем код с гит-пулл-тома;
— поднимается php-fpm-контейнер с этим синхронизированным томом;
— старый php-fpm-контейнер глушится, освобождая для повторного использования свой rsync-том.