Как отмечают многие эксперты, агрегаты и иные тактические паттерны вторичны для true-DDD. А первично общение с бизнесом, понимание истинной природы запроса. Именно это позволяет создавать фичи максимально заточенные под потребность. Разработчики, которые практикуют DDD обязаны выходить за пределы техники и примерять себе роль продакта.

Перевез посты с гугла, к сожалению потерялись оригинальные даты ¯\(ツ)/¯

Заказчик, чьи сайты я поддерживал ранее, обратился с тем, что сайт лежит и отдает 500 ошибку. У него стандартный сайт на ASP.NET WebForms, не скажу, что очень нагруженный, но бывали проблемы с производительностью базы данных (MS SQL Server на отдельном сервере). Недавно сервер БД поменяли и перенесли данные. Этот сайт не основной бизнес заказчика, поэтому практически не обслуживался. У него не настроено никакого мониторинга и сбора метрик и вообще за ним особо не следят.

Иногда случается, что надо перенести джобы с одного сервера на другой. Или сохранить джобы в качестве скрипта и положить в репозиторий. Если у нас всего два-три джоба, то можно использовать "Script Job As" >> "CREATE To" >> "...выберите куда...". Но что если у нас десятки джобов?

Как-то, просматривая вопросы на Stackoverflow, наткнулся на вопрос, связанный с коллекцией кук в запросе и ответе. Вкратце вопрос можно сформулировать так:

В декабре 2014 года прошло сразу два мероприятия: ‪#‎agilekitchen‬ и ‪#‎leancoffee‬. Я попробовал сформулировать несколько тезисов по итогам обсуждений:

Наш проект уже почти полгода живет в agile-стиле. Мы пробуем различные подходы и пытаемся применять все, что нам подходит и делает жизнь проще. К сожалению, никто из нашей команды ранее полноценно не работал с использованием гибких методологий. Процесс внедрения SCRUM идет медленно и не всегда эффективно: мы сами доходим до того, что описано в статьях-книгах.

В октябре команда проекта Zarplata.ru перешла на скрам, предпосылки и ожидания я описал ранее. За прошедший квартал мы провели четыре спринта, старались следовать рекомендациям и общепринятым установкам. Наши договоренности остались в силе: все спринты были трехнедельными, был инженерный день, ретро и планирование.

С первого октября 2012 года мы начинаем использовать скрам. Команда на первую итерацию: 1 тестировщик и два программиста. Верстка и дизайн за границами (почти не потребуется).