Когда-то давно я пришел на Bitbucket именно из-за поддержки и Git и Mercurial.
Времена идут, продуктовые стратегии меняются, старое выпиливается.
Самое главное, что пользователям дается время свалить с битбакета или мигрировать на Git.
Архив рубрики: Разработка
Про DDD
– есть бизнес и его виденье мира
– есть разработчики которые выражают бизнес процессы в коде
– есть проблема перевода требований из языка бизнеса в код, потому что модель бизнес процессов часто засоряется инфраструктурной фигней
– “проблема перевода” приводит к тому что спустя время сложно понять как работает модель, сложно убедиться что модель все еще соответствует бизнес процессам
– идея DDD в том что бы формировать единый язык и выражать все идеи бизнеса в коде максимально придерживаясь этого единого языка. В идеале ты можешь взять код, посадить рядом нового разработчика и доменного эксперта и спросить по коду у оного что это такое.
– упор на именование, формирование правильных отрошений, глоссарий, и как следствие попытка полностью изолировать модель от инфраструктуры.
Про CentOS…
Пустой дистрибутив. Абсолютно любое действие в нём начинается с tar zxf, configure, make install. Разговоры о его надежности заканчивается через полчаса после необходимости поставить какой-нибудь htop или monit. Ещё через час после разломанного в крошево дистрибутива заканчиваются рассказы о том, что существуют какие-то внешние репозитории, в которых что-то есть.
Про фичи, контексты и boundary context
Фичи формируют контексты (boundary context). Контексты пересекаются но в целом весьма изолированы. Их нутро не зависит друг от друга.
Возьмем к примеру каталог товаров и прикинем какие у нас тут есть контексты:
- пользователи — авторизация, восстановление доступа, управление профилем
- ордеры — весь цикл жизни ордера в системе
- каталог товаров — управление каталогом, просмотр деталей о продукте
- поиск — весь поиск.
В этом примере наиболее интересный “модуль” — это поиск. Он может искать для нас продукты в каталоге и ордеры. Но они ничего не знает о ордерах или продуктах. Скажем когда мы ищем ордеры — мы просим модуль поиска найти для нас “ордеры” и он всего-лишь вернет нам айдишки и информацию которая важна нам для поиска. Далее для этих айдишек мы можем уже запросить детали у модуля каталога.
Синхронизация этих модулей — ивенты. Кто-то обновил продукт — кидаем ивент — синхронизируем данные в других контекстах.
Профит тут в том что мы можем отдельно посадить чувака заниматься поиском, и отдельно чувака заниматься ордерами. Можем перевести поиск на свою СУБД которая хорошо умеет полнотекстовый поиск (например эластика). И при этом если у нас добавляются фичи в каталог — это не сильно влияет на поиск.
https://habrahabr.ru/company/englishdom/blog/328550/
Про гибкость
Гибкость — это когда нет зависимости между моделей данных, бизнес логикой, поведением и местом хранения данных.
https://habrahabr.ru/post/327746/