Моё знакомоство с предметметно-ориентированным проектированием началось не совсем книги, а конференций 2019 года. Встречи с коллегами на AgileDays 2019, DDDevotion, DotNext, ArchDays позволили ясно увидеть два лагеря: не многих у кого DDD заработал, и многих кто хотел, но не взлетает. Это натолкнуло на длинные рассуждения, что DDD применим только при определённых производственных отношениях, а команды должны эффективно обучаться и применять на практике DDD.


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



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


Первое что я почерпнул — исторический материализм — производственные отношения определяются экономическим базисом. Тут проходит первый водораздел индустрии. Если ваш продукт делается на заказ (товар), собственник продаёт вашу почасовую работу, рефакторинг не наступит, а разделение труда на аналитиков/разработчиков/тестировщиков/поддержка оправдано. Если продукт — это сервис, т.е. у него много пользователей-потребителей с одной стороны, и есть манипулирования эластичности спроса, выраженная через необходимость развития с другой стороны, то в этом случае нетоварного производства уместен Scrum и XP, CI/CD, DDD, TDD, микросервисы и облачные функции. Поэтому DDD будет в первую очередь там, где: 1) продукт реплицируемый, т.е. сервис; 2) корректно работает гибкий менеджмент.


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


Кружковая стадия


По мере развития капитализма в России к концу XIX века, появлялось всё больше рабочих трудившихся бок о бок в промышленности. Экономика на ту пору как и сегодня имела полупереферийный характер. Усиленная эксплуатация рабочих приводила к стачкам и забастовкам. Крайне модный модный в то время в Европе коммунизм, быстро завладевал умами интеллигенции. Чтобы помочь сложившейся системе производственных отношений обратится из гусеницы в бабочку, эти люди отправлялись в народ создавая кружки. Кружок — это форма взаимодействия между человеком более "начитанным", разбирающимся в теме, и обычными рабочими, которые не могли получить образования, или не могли в полной мере, или не видели в этом необходимости.



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


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


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


Развитие цели через развитие организации


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


Левое движение для синхронизации этой цели между отдельными кружками, формирования основного костяка будущей партии использовало печатные органы, доносившие свою позицию по разным вопросам. Проецируя это на нашу область можно сделать аналогичным, работая в двух направлениях. Во-первых, нужно сформировать общий SeedWorks, с которым будет работать большинство, который смогут формировать все активные члены вашего сообщества. Во-вторых, уместны внутренние доклады, статьи, корпоративные странички на хабре. Цель их противопоставить свой подход остальным, чтобы получить обратную связь, обличить тех, кто ведёт за собой людей по ложному пути, ради личных интересов или какого-либо волюнтаризма. Хороший пример вижу в журнале Современная Архитектура, который выносил на обсуждения те или иные решения, будет выступать с критикой других решений, декларировал новые концепты. СА стал очень мощным катализатором авангарда, на котором вызревала архитектура.


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


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


Кустарничество — состояние, когда в условиях борьбы движение захлёбывается, потеряв ключевых участников. В разработке также может возникнуть такое состояние. Уход ключевых участников всегда возможен, и подобные риски нужно диверсифицировать, передавая знания коллегам, формируя разделы в конфлюенсе/вики, делая статьи.


Хвостизм — оппортунистическая идеология и тактика следования в хвосте событий, приспособления к отсталым, стихийным элементам движения, отрицающая роль политической партии и передовой теории в рабочем движении. Хвостизм всегда связан с тем, что у ответственных на определённых уровнях возникают свои особые интересы, которые могут идти в разрез с интересами проекта и других работников. Я заметил, что есть маркерное выражение, про эволюцию и революцию, которое очень точно говорит о таких интересах, ведь изменения сначала затрагивают частные интересы, а потом любые другие.


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


Что насчёт меня?


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


К сожалению, для себя я на практике подтвердил, что для успешного и всеобъемлющего использования DDD, микросервисов, DataMesh, нужно чтобы продукт был востребованный и массовый. Настолько, что на нём будет много человек, будет здоровый Agile фреймворк в действии, будет время на технорадары и исследования. Кроме того, стало очевидно, что на рабочем месте уместно объединяться, выставлять не только требования связанные с трудовыми отношениями, но и к самому процессу.




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

Комментарии (6)


  1. RetroStyle
    23.08.2021 22:42
    +3

    Зачем рабочим бороться за свои права вполне понятно. А зачем бороться за DDD совершенно не ясно. При чем тут вообще левое движение? И дальше рушиться все построение: кружки и т.д. За это больше платят? Или это как раз еще один способ усиления эксплуатации? Тут скорее будет уместна песня Владимира Высоцкого, про то что

    "...вот откапаем, он опять

    начнет три нормы выполнять

    начет стране угля давать - и нам хана".


    1. mad_nazgul
      24.08.2021 07:19
      -1

      И тут мы плавно подходим к эффективности социализма и социалистических отношений.
      <:o)


      1. RetroStyle
        24.08.2021 09:41

        Да никуда мы не подходим. Статья глупая.

        Если попытаться понять суть, то она сводится к следующему.

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

        2. Второе. Автор рассказывает о кружках, как об эффективной форме популяризации идеи. Утверждение мягко говоря спорное. Большевики вынуждены были использовать форму кружков по той причине, что во-первых, не имели возможности распространять свои идеи через другие формы: лекции, СМИ, открытая агитация. А во-вторых, потому что значительная часть целевой аудитории была элементарно безграмотна. Так что даже если и удалось напечатать и переправить тираж "Искры", надо было что-бы кто-то эту газету вслух прочитал. Как только первое и второе ограничения были сняты, кружки очень быстро сошли на нет.


    1. Ekstrem Автор
      29.08.2021 10:30

      Зачем рабочим бороться за свои права вполне понятно

      Я лично не знаком с работниками в сфере разработки, которые считают что за что-то вообще стоит бороться, зато готовы просто поменять место работы.

      зачем бороться за DDD

      DDD просто инструмент. Предпринимать усилия стоит только ради команды, ради удовлетворения себя в труде.

      При чем тут вообще левое движение

      Статья про распространение знаний между работниками. ЛД, такое как я его вижу, вообще не причём - оно продолжает где-то там косплеиться)

      Автор постулирует, что DDD подходит для проектирования сервизов и не подходит для продуктов. Причем это никак не аргументируется.

      автор пытается привязать сюда определение "товарного производства"

      см. сюда

      Автор рассказывает о кружках, как об эффективной форме популяризации идеи. Утверждение мягко говоря спорное.

      Я рассказываю о кружках, как о методе развития команды. Посетив конференцию, почитав две книги не освоить сложных тем всей командой.


  1. BasicWolf
    24.08.2021 09:29

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

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

    И это только культурная составляющая, а сколько сил приходится тратить на техническую сторону дела! Товарищи переходящие с монолита на распределённые системы просыпаются через пол-года со словами "I know kung-fu". "Кружки" программистов тянущих друг-друга вверх становятся необходимыми. Работе в паре или "толпой" становится не роскошью, а необходимостью. Помимо улучшений в качестве, мы получаем моментальное распространение знаний.

    Я очень советую вам прочесть книгу "Turn the ship around" (L. David Marquet). Возможно именно она станет катализатором, который поможет преодолеть все перепоны и укоренить практики DDD.


    1. Ekstrem Автор
      29.08.2021 10:49

      Спасибо что правильно меня поняли и за совет. Обязательно почитаю!