6

5 способов провалить IT-проект с помощью DDD

Спустя годы после выхода "Domain-Driven Design", идеи Эванса вошли мейнстрим. Разработка через моделирование должна была уменьшить неопределенность, позволить разрабатывать ПО за меньшее число итераций. Должна была, но ничего не вышло.

На собеседованиях и митапах я слышу

Мы пытались внедрить DDD, но у нас не получилось

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

5 способов провалить IT-проект с помощью DDD Программирование, IT, Факап, Длиннопост

Способ 1: Попытка дословно следовать книге Эванса

У большинства книг по методикам разработки одна и та же болезнь -- хорошо сформулированных идей\эвристик\дельных примеров страниц 20 от силы. Остальное занимают вдохновляшки и бесполезные листинги. В качестве проверки можете взять "Domain Driving Design" или "Рефактринг" Фаулера и заклеить стикерами все листинги. Для восприятия ничего не изменится. Аналогичное работает с большинством примеров в книге Эванса. А все стенограммы интервью можно заменить на список

* Общайтесь с пользователями и заказчиками.

* Уточняйте с ними модель.

* Для реализации нужно будет не все, что говорит заказчик.

И таких сверхобщих рекомендаций очень много. Подобное может сработать, только если читатель интуитивно (и при этом правильно) понимает, как проводить такие интервью, какие вопросы задавать. То есть, если читатель уже умеет общаться, то стенограммы ему не нужны. Если не умеет -- стенограммы бесполезны, потому что не поясняют "как".


Можно взять эти стенограммы, как шаблон, и попытаться провести интервью с заказчиками по нему. Тут же появляются проблемы:

* Собеседник будет вести себя иначе, чем это указано в шаблоне.

* Ответы собеседника могут быть как очень емкими, так и почти бесполезными. Строить наводящие вопросы без конкретного понимания "А что же я ищу" бесполезно.

* "Ну вроде все понятно". Иллюзия понимания от неоднозначных формулировок превращает любую начерченную при разговоре схему в мусор.

Аналогично с другими комментариями\призывами

* Домен должен быть изолирован!

* Архитектура должна следовать модели!

Это хорошие лозунги, но они не объясняют, как именно это делать.


Другой подводный камень в дословном следовании Эвансу --- отображение модели в код.

Эванс в своей книге следует очень вредному представлению из объектно-ориентированного проектирования, что "объект --- это существительное, а метод\функция -- глагол". При том, что описание действий в виде объектов распространенная практика. Даже у банды описаны шаблоны "Стратегия" и "Команда", которые как раз оперируют действием как самостоятельным понятием. Иногда эта ошибку обходят интуитивно, если в обсуждении или формулировке задачи использовались отглагольные существительные.

От этой ошибки на уровне интуиции привиты те, кто писал на Prolog или Lisp. Это одна из причин, почему это работает у Эванса, но не сработает у вас.


В книге содержится достаточно много цельных переносимых идей, но за обилием призывашек и бесполезных примеров теряется суть многих из них, из-за чего внедрение проваливается.


Способ 2: Ограничиваться только предметной областью задачи

В радикальной форме выглядит так: "насаждение доменной модели разработчикам всех уровней системы".

В чем проблема:

1. это полностью противоречит призыву к изоляции доменной логики.

2. полностью игнорирует тот факт, что многие сугубо технические задачи решаются в пределах своего собственного домена.

Даже если у вас получится изолировать доменную логику на отдельном уровне, код, который ее поддерживает, все еще может выглядеть как каша. И скорее всего будет.


Внедрение DDD во многих компаниях начинается с попыток выделить клиентскую логику в отдельные программные единицы. На коммерческих проектах это Авгиевы конюшни. Попытка вынести сразу все -- уже серьезное испытание для нервов и кошелька заказчика. Но даже если заказчик готов на это пойти, то у нас возникает вторая проблема:

Одна только изоляция бизнес-логики никак не облегчает добавление новых функций и исправление реализации старых.

А все потому, что техническая часть все еще каша. Просим заказчика потянуть еще годик?


Способ 3. Строить модели по исходным формулировкам

Исходные формулировки задач полны смыслового мусора. Для пользователя он имеет смысл, вот только в решении задач такие вещи бесполезны.

Пример из педагогики. (Утащил у Крыловой М.Г.)

Проблемы с математикой из-за противня.

Дано:

Девочка из 4 класса,

Задание по математике про дроби и пирожки.

Подобные задачи решались с успехом самостоятельно

Найти:

Почему именно эта задача стала трудна?

Решение:

Через 10 минут мучений была вскрыта проблема - " а что такое противень?"

На удивление, мой ответ о назначении противня девочке помог. Проблема была устранена и задача легко решилась.

Можно посмеяться над девочкой, а можно посмотреть в переписку с аналитиком и увидеть в девочке себя.


Первый шаг при моделировании -- очистить задачу от таких "противней", иначе модель будет перегружена деталями и левыми объектами, которые вообще не имеют отношения к задаче.

Если пытаться моделировать "как есть", то в модели появятся противень, духовка, режимы выпекания и т.д.

А нужно-то было сделать калькулятор.

Заказчик ни при чем -- он пекарь. Тут вина программиста, что побежал моделировать домен, не очистив формулировку (как он это уже делал в школе, на уроках физики).


Способ 4. UML

"Моделирование -- это про UML?"

Нет.

Отдельные диаграммы UML гипотетически могут быть полезны при проектировании программной системы. Но это не заслуга UML, как стандарта. Информацию в принципе проще воспринимать визуально, только и всего. Модель же, в зависимости от исходной формулировки и особенностей технических ограничений, может быть выражена чем годно: таблицами, графоподобными конструкциями или даже чистыми формулами.

Для описания моделей UML одновременно излишне перегружен и крайне ограничен. Другая его проблема -- стандарт порожден из Java-образноного понимания ООП, которое работает только в пределах самой Java и то с попеременным успехом.

Попытка использовать UML для описания моделей -- гарантированный провал.


Cпособ 5. Слоистая архитектура

Снова вернемся к книге Эванса.

Описывая детали технического контекста, он постоянно упоминает слои. Однако не будем забывать, что слои -- это подход Java фреймворков, который не работает за их пределами.

Использовать Java примеры Эванса -- гарантированно провалить архитектуру.


Наиболее адекватный взгляд -- юниксовый. Каждая часть программы ограничена техническим контекстом и решаемой задачей. Количество промежуточных обработок зависит не от концептуального количества абстрактных слоев, а от того, сколько подзадач и в каком порядке нужно решить. То есть мы на все смотрим, как на паутину задач, решение которых приводит к нужному результату.

Попытки раскидать задачи "по слоям" превращаются в игру в пятнашки с постоянным нарушением технического контекста.


CODA

Каждому контексту по модели.

Каждой модели свободное представление.

Каждой задаче по решению.

Каждому решению по реализации.

Объектно-ориентированное описание бизнес-процессов -- в мусорку.


Пристать со вопросами на тему IT и современной мультипликации можно тут: вк

Поспорить на тему статьи, болгарской кухни и музыки позднего средневековья можно здесь: твитор

Дубликаты не найдены

+1

Только что мы тут все прочитали 3 страницы нахер ненужной воды про то что книга одного чувака про DDD это бесполезная вода.

0

Все что вы написали – сплошные выводы, причем довольно категоричные, а вот на чем они основываются, непонятно. Я бы с большим интересом почитал про ваш опыт внедрения DDD в каком-нибудь проекте. Кстати, DDD работает не только для ООП. Очень рекомендую посмотреть по теме

раскрыть ветку 5
0

Да, я читал книгу этого чувака. Он допустил достаточно дурацкую ошибку. Начал через призму логического программирования прикручивать DDD к F#, хотя, F# сам по себе из коробки уже имеет нужные механизмы для синтаксически непротиворечивого выражения моделей. Не лисп, конечно, но тоже неплохо.

раскрыть ветку 4
+2

Боже, как меня тошнит от такого снобизма: "допустил дурацкую ошибку", "DDD в мусорку". Напомню, речь идет о довольно уважаемых людях в IT сообществе, чьи книги и выступления, принесли пользу многим разработчикам. Вы бы сначала научились излагать свои мысли, а потом критиковали всех и все.

раскрыть ветку 3
Похожие посты
131

Во все тяжкие: Веб-разработчик с нуля. 11 месяцев

Во все тяжкие: Веб-разработчик с нуля. 11 месяцев IT, Программирование, Карьера, Javascript, Веб-Разработка, Frontend, Web, Длиннопост

А вот теперь меня уволили.. Месяц был насыщенным.. И не веселым.


Цель — Senior Frontend Developer.

Язык: JavaScript.

Возраст: 28 лет;

Работа (настоящее время): - Trainee Frontend Developer в компании "Корус Консалтинг СНГ";

Локация: г. Санкт-Петербург.


Привет всем моим подписчикам! Как вы там? У кого какие успехи?


Меня вот за этот месяц уже успели уволить разок, а сейчас я уже "работаю" в крупной компании. Ну давайте обо всем по порядку.


Я сделал десятки откликов на всем известной площадке для трудоустройства и конечно, было довольно много откликов с разного уровня тестовыми заданиями. Ходил на несколько собеседований, но что-то дело с мертвой точки не сдвигалось. Либо я не тянул и не мог тестовое сделать, либо после, вроде как успешного собеседования - тишина, не ответа ни привета.


Решил сменить тактику и опубликовал в своем твиттере клич о поиске работы. И тут на меня вышел работодатель, предложил вакансию верстальщика-разработчика.

Компания американская, стартап из Силиконовой Долины. Проект - свой браузер (расширение, надстройка над браузером на базе Chromium). Я подумал - крутой проект, плюс работа удаленная, зарплата в долларах, я не один фронт на проекте - предел мечтаний просто. Созвонились по скайпу с ведущим фронтом, я ответил на все вопросы, рассказал о своем небольшом опыте, вроде все обсудили и обо всем договорились.


Часа через два я  уже общался по видеосвязи с руководителем и инвестором стартапа, который сидел в солнечной Калифорнии и рассказывал о работе в их команде.


Еще через час я уже сидел и читал договор на английском и искал в нем пункт о продаже почки. Но нашел только свою зарплату в долларах. Если перевести в рубли, то примерно зарплата миддла в РФ. В общем, все подписал, мне выдали все доступы ко всяким jiraм и корпоративным почтам. Я не мог нарадоваться! Завтра в бой, с утра на митап или как там это называется. Знакомство с командой! Уже представил в мыслях как через пару месяцев смогу загорать на Бали и работать под пальмой. Но рано радовался..


На следующий день мне поставили задачи, задача была немного расплывчатой, входных данных мало(макет корявый). До обеда я только настраивал окружение, в чем мне помогал руководитель фронта и только после смог приступить к задаче. Но только я посмотрел на код и на то, как устроен проект, я понял, что это будет непросто..


Я увидел настоящий ад для верстальщика. Чтобы увидеть изменения нужно ввести пару команд в консоль, дабы пересобрать проект и после этого перезагрузить браузер. А так как это расширение, то там не совсем удобно работать с девтулзами. Но самое сложное - это их самописный фрэймворк, на котором все держалось. Я вообще не понимал как данные и элементы появляются на странице в расширении. То есть, просто так взять и добавить в код тег, в надежде его увидеть на странице, не получится. Я сидел и пытался понять, как же эта тварь работает. Документации к фрэймворку мне не дали.


К вечеру моя голова уже разрывалась на части, я чувствовал себя ничтожеством и раскатал руководителю сообщение о том, что мне нужно разобраться глубже как это все работает и что нужно что-то сделать с релоадом страницы и автоматической сборкой после изменений, иначе верстать в слепую - это тяжко и долго. Да и вообще, на данный момент я не могу сдвинуться, нужно осваивать фрэйм.


Но спустя пару часов руководитель и инвестор всего проекта предложил созвониться. Я почувствовал что-то неладное. По его тону я понял, что это всё. Говорил, что-то вроде: "Руководитель фронтэнда говорит, что переоценил свои возможности по обучению и уделению времени джуну" . В общем, они не готовы были вкладывать время в мое обучение. Он предложил прекратить сотрудничество и компенсировать мой рабочий день, но чего уж там.. Мне было не до этого. Я расстроился. Это был удар. Неожиданно просто все произошло, вот я и приуныл.


Изначально то мне сказали, что мы начнем с простых задач и потихоньку будем усложнять и делать задачи сложнее. А по итогу даже не дали времени на освоение их стека. Один день - это мало, я считаю. Но у них скоро должен был быть релиз, видимо из-за этого меня быстро отправили восвояси. Хозяин барин. Что сказать.


Вот так прошел мой первый и последний день работы в американском стартапе из Силиконовой Долины.


Помимо этого, за несколько дней до устройства я сдал тестовое задание в другую компанию и прошел во второй этап тестирования (очный этап). Но этот очный этап выпал на мой первый рабочий день в стартапе, поэтому я на него не смог пойти. В итоге я потерял и эту работу и возможно вторую ( так как первое тестовое мое оценили хорошо, а на второй этап я не пошел). Ну да ладно.


Далее я встряхнулся, сделал выводы и написал в ту компанию, в которую должен был идти на второй(очный) этап тестирования и объяснил ситуацию. И мне пошли навстречу, предложили сделать тестовое удаленно! Но оно было на время, ровно на 4 часа, с контролем времени. И вот на следующий день я выполнил эти два задания. Честно говоря, давно так не стрессовал. Еле уложился в 4 часа. Всё, сдал. Отправил.


Через пару часов получил фидбек, что сделал все замечательно и меня принимают в их проект. Что за проект вы спросите? Дебютный проект компании "Корус Консалтиинг СНГ". Крупная компания, дочка Сбербанка. Суть проекта - это два месяца оплачиваемой учебы (по срочному договору), вы учитесь и вам платят среднюю зп джуна по рынку! Не круто ли? После - трудоустройство в один из их проектов. А там ДМС, белая зп, английский и всякое такое.


Сегодня закончился третий день учебы. И знаете что? Это то, что мне было необходимо. Преподаватель, код ревью, лекции - очень интенсивная учеба и не простые практические задания. Нас в проекте 6 человек, возраст ребят и одной девушки от 22 до 30 лет. Мы общаемся, обмениваемся опытом, в общем - круто. И еще плюс: сегодня нас перевели на удаленку, в связи с чем - сами понимаете :) Стало еще удобнее.


Такие дела. Не останавливаемся и движемся к цели!


Ну и по традиции. Что я сделал и изучил за последний месяц:


1. Дочитал книгу "Грокаем Алгоритмы". Кто подписан на мою инсту уже давно в курсе;

2. Разобрал примерно половину книги Мартина Фаулера "Рефакторинг кода на JavaScript";

3. Разобрал процентов на 20% книгу Эрика Хэнчетта "Vue.js в действии".

4. Написал пару приложений( пару недописал) и мини проектов. Искать в гитхабе.

5. Я оформил свое резюме прямо в гитхабе. Как вам?

6. Посмотрел конференцию от Яндекса «Я ❤ Фронтенд 2020»; рекомендую!

7. Посмотрел конференцию от Яндекса «Я ❤ Фронтенд 2019»; рекомендую!

8. Сходил на конференцию Piter JS #45;

9. Познакомился с библиотекой Lodash;

10. Познакомился и попрактиковался с шаблонизатором Pug;

11. Познакомился и сделал пару проектов по WebGL(Tree.js);

12. Посмотрел где-то 1/4 курса ШРИ 2018 года от компании Яндекс.


Ну, что ребята? 11 месяцев позади и кажется, что у меня вот только-только что-то начинает получаться осознанное. Так, что кто думает, что можно стать более менее понимающим веб-разработчиком за 3-4 месяца - чушь. Вспоминаю свои первые собесы - стыд и срам.


Год интенсивного и каждодневного изучения и практики дадут плоды, но небольшие. Большие - дальше.


Успеха Вам! Подписчикам здоровья и удаленной работы в этой больной мировой обстановке! До встречи через месяц!


Артем, OWIII.

Показать полностью
1114

Модульный код

Когда меня друзья спрашивают, что такое модульный код, чем он лучше, и почему я так от него кайфую, я показываю эту картинку. На что они говорят, что судя по лицу последнего, преимущество сомнительное :)

Модульный код Программирование, Программист, Код, IT, IT юмор, Айтишники
3905

Ваши одноклассницы тоже делали цветовое выделение текста до того, как это стало мейнстримом? И вы считали это девчачей придурью?

Эй, девчонки, делающие записи 50ю различными цветами, ну и где вы теперь? Вы все еще продолжаете использовать все эти цвета?

Ваши одноклассницы тоже делали цветовое выделение текста до того, как это стало мейнстримом? И вы считали это девчачей придурью? IT, Программирование, Юмор
237

Истории уже не инженера по гарантии, часть 3.

Наверное, последняя история про ИТ. Как оно бывает и что там вообще может быть. Я понимаю, что большинству это не интересно, напишу только для тех, кто просил, благо они в подписчиках.

На этот раз никакой мистики.

Итак, года 4 назад мы начали разрабатывать свою продакшн систему. Это была некая CRM с очень тяжелой базой данных. Работала на ней контора оборот которой составлял примерно 5 миллионов в день. Надо понимать, что простой системы даже в 1 день это потери, пусть даже в 10% это 500 000, а в реале там больше.
Изначально был разработан план резервирования системы. Планировали мы построить второй ЦОД, забрать железо от старой системы, чуть проапгрейдить и сделать копию. Железки пришли, начали делать и выяснили, что температурный баланс серверной поплыл – перегревается. Изначально в серверной планировалось три кондея, в работе – 2. Надо ставить третий. Делаем заказ, пришли люди, ставят. И вот в процессе установки прибегает ко мне один из ребят, занимающихся почтой с фразой – «серверную затопило».
Честно говоря – мозг поплыл сразу. Как на автомате я дошел до серверной, увидел человека пытающегося заткнуть трубу из которой хлестала вода, пнул своих ребят отключать питание, что-то отключил сам, в общем – отработали. Обесточили все, начали выносить сервера. Оказалось, что вот та труба на потолке, обозначенная как «система вентиляции» это жидкостный привод вентиляторов. Если бы раньше знать! Фактически у нас утопили оборудования на 20 миллионов рублей. Пока пацаны выносили и разбирали сервера и СХД я уже начал звонить, думать и так далее. Вариантов немного, нужна была полная копия системы, правда есть шанс перейти из SMB в Enterprise, не создавать копию, а взять нормальную систему повышения плотности, blade или что-то в этом роде. Начали. Как мы собирали по всей Москве нужные нам железки разговор отдельный. Что-то выкупалось со скидкой у IBM, а что-то бралось с накруткой процентов 20-30, потому как надо и завтра. Но купили.
А потом, потом мы фактически жили на работе месяц. Да, с премией, да с оплатой переработок, но так я не пахал до этого никогда. Восстановить систему, сделать тот самый резерв и все это в кратчайшие сроки. Похвастаюсь – восстановление боевой части системы прошло за 3 дня. Полной примерно за 10.
Ну и выводы – да, все было криво. По большому счету мы сами виноваты, что пришлось столько пахать, сами виноваты, что вообще допустили подобное. Но, как говорится – экономия. Вопросы по надежности были задолго до инцидента и убедить руководство в необходимости превентивных мер не удалось. Наверное, я в этом и виноват. Кто знает?
Показать полностью
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: