В заметке содержатся мысли о прохождении курсов по DDD в декабре 2024г. Сама заметка это результат практики Мышления письмом, изучаемой в рамках курса Практики саморазвития от ШСМ.
Нельзя сказать что прохождение курсов сделало меня знатоком DDD. Стоит их рассматривать скорее как поверхностный обзор технологии с разбором некоторого числа практических примеров. Конечно в курсе (на 10 раб дней по 4 ч в день + домашнее задание на выходные ) присутствовали практические занятия в виде совместного анализа предметной области (системы проведения аукционов), но они служили скорее иллюстрацией для изучаемой теории.
Что меня больше всего удивило? Domain Driven Design (DDD)
оказался совсем не про программирование, как я считал до прохождения курсов. Это скорее технология создания непротиворечивых моделей окружающего мира.
Чистый практический подход, или набор приёмов (метод ), который описывает что и как нужно сделать чтобы эту самую модель предметной области получить.
Как составить словарь(глоссарий) проекта? Каких экспертов в предметной области необходимо привлечь и как выстроить общение в процессе их опроса? Как выявить структуру системы, основные элементы(объекты) и взаимосвязи между ними. И наконец какие артефакты должны описывать получившуюся модель.
Рассмотрели в каких случаях такой подход применим, а в каких лучше этим не заниматься. Если кратко, то чем сложнее система, тем сильнее необходимость в построении и постоянной актуализации модели её предметной области. Для малых и/или простых систем DDD может быть излишне тяжёл, и дорог. Хотя на мой взгляд, для разработчика очень важно иметь краткое и компактное описание предметной области, вне зависимости от того, чем он занимается и конечного размера создаваемой системы.
Особо запомнилось то, что недостаточно на старте выполнить один проход DDD и забыть про полученное описание. Если система живёт, и развивается, то вместе с ней должна постоянно изменяться и её модель.
Так же хотел обратить внимание на такой момент - в процессе обследования/проектирования, бизнес вполне может понять что никакая автоматизация ему не нужна, или обойдётся слишком дорого, т.е. разработка себя не оправдает. И это нормальный результат, вполне приемлемый и даже желательный для разработчика системы, т.к. позволит не ввязываться в заранее неудачный/провальный проект. Вроде бы ничего нового, но периодически вспоминать об этом очень полезно.
В процессе проектирования в модели предметной области должно быть чётко выделено ядро (core), т.е. именно та часть бизнеса, которая приносит деньги, является уникальным конкурентные преимуществом.
Выделяется она с конкретной прагматической целью, определить какая часть системы уникальна и должна быть реализована силами разработчика, а какая с использованием доступных библиотек или внешних по отношению к системе сервисов (отдана на аутсорс).
Самое комичное, или интересное, на мой взгляд в таком выделении, это возможность ядра не обнаружить 
Сей прискорбный факт означает что бизнес развивается по инерции, и лишь в силу случайного стечения обстоятельств ещё жив и приносит деньги. Конечно это вырожденный случай, и возможно был приведён только в качестве примера важности выделения ядра системы, но… запомнился хорошо.
За правильность и адекватность описания DDD как подхода не ручаюсь Впечатление некоторой тяжеловесности, сложности и избыточности применяемых методов присутствовали постоянно, но рекомендовать изучение DDD однозначно можно и нужно.