Впечатления противоречивые, но в целом мне понравилось. К тому же я понял несколько важных вещей.
Во-первых нельзя пускать на такие мероприятия простых (особенно начинающих) разработчиков. Им становится скучно и они задают вполне логичный вопрос: "А как мне вся эта научная фигня поможет к пятнице нупырить тонну кода". Но несмотря на то что мне (как начинающему) тоже показалось, что было слишком много теории, и маловато примеров. Так вот несмотря на это, мы товарищей, спрашивающих дурацкое, презираем. Потому что, когда начинающий разработчик приходит посоветоваться к архитектору (как к старшему товарищу по оружию) с вопросом "как лучше бы тут сделать", то архитектор должен иметь в голове всю эту "заумь", чтобы выдать простой, логичный и непротиворечивый ответ. В целом ему не обязательно вываливать на голову бедолаге-новичку все принципы и ценности DDD, достаточно будет сказать "вот тут так лучше потому что"... Вообщем, вы поняли.
Так же понятно почему DDD хорошо взаимодействует с Agile. DDD рассматривает модель/архитектуру/дизайн проекта как общее поле знаний, а не некое закрытое знание доступное только избранным (архитекторам, ПМ-ам, тимлидам, я не знаю). Т.е. одинаковая модель существует у всех участников команды в головах. А аджайлисты любят, когда что-то в команде существует в головах и во всех головах оно одинаковое. Это дает им кроссфункциональность членов команды и все такое.
Однако все это хорошо работает если перед тем, как внедрить всем в голову модель вашего проекта и всем сказать - "вы теперь тоже разарбатываете архитектуру (причем для всех)", перед этим внедрить всем в голову "модель использования DDD". Сначала команде и заказчикам придется объяснить все про DDD, эти общие словари, принципы, ценности и прочее и только тогда про модель непосредственно самого проекта. Собственно, проблема внедрения любых методологий. И DDD в этом смысле не самая простая для понимания. Для восприятия я бы сказал. (И это явно влияет на популярность DDD). Мало понять что-то надо это еще и принять, применить к себе, чтобы пользоваться этим.
Ну, и на закуску интересное наблюдение про 1С. По сути 1С это:
а) предметный язык,
б) платформа принудительно заставляет пользоваться общим языком (UL), изначально сформированным экспертами;
в) понятен экспертам.
За то, что 1С прилично адаптирован к DDD говорит тот факт, что в реальности существует множество "программистов 1С", которые появились из бухгалтеров (т.н. "доменных экспертов"), по принципу "я посмотрел, там все было просто и я решил почему бы самому не стать программистом".
Зацените синтаксис:
Все интуитивно понятно, не так ли?Процедура КнопкаВыполнитьНажатие(Кнопка)
ДокументРеализация = Документы.РеализацияТоваров.СоздатьДокумент();
// ... еще какой-то код ...
Если ДокументРеализация.Проведен() Тогда
Сообщить("Документ проведен!");
КонецЕсли;
КонецПроцедуры
Это безусловно не идет на пользу "программированию 1С", в качестве общей дисциплины программирования, так как бывшие бухгалтера не хотят ничего знать ни о рефакторинге, ни о моделях, ни о вообще базовых алгоритмах (отсюда и мемы про криворуких 1С-ников, и тонны страшнейшего кода), но с другой стороны ярко иллюстрирует что 1С - full DDD ready.
Конечно, в нем есть и "не ready" моменты. Например, отсутствие толковых инструментов тестирования. С другой стороны такие инструменты можно воспринимать как артефакт универсальных языков, в котором предметный язык нуждается в гораздо меньшей степени, что опять же доказывают толпы программирующих бухгалтеров (оно же у них как-то работает все).
Итак, вебинар удался, еще раз спасибо Максиму.
