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

DDD не на коленке, а за дорого ;)

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

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

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

Поначалу мне попали в работу легаси проекты, архитектура которых была Transactional Script или Table Module. Модули требовали рефакторинга, решения тех.долгов, встал вопрос о целесообразности рефакторинга и альтернативных реализаций. Как инженер, я решил, что единственный верный шаг прокачать себя, а затем и команду, теоретически, а потом предпринимать стратегические шаги. Если с TS и TM архитектурами я был хорошо знаком, то шаблон Domain Model был знаком только в самых общих чертах по книге Мартина Фаулера. На фоне общения на конференциях, чтения матёрых книг про рефакторингу, SOLID, Agile, пришло понимание почему именно изучение подобных архитектур оправдано: в Enterprise есть смысл стремиться к максимально адаптируемому к изменениям ПО, а для доменной модели изменения требований стоят несравнимо дешевле в реализации. И меня напрягало, что как раз доменные модели я если и применяю, то по наитию, бессистемно, невежественно. Так началось моё знакомство с предметно-ориентированным проектированием.

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

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

Если вам необходимо спроектировать взаимодействие двух систем, в каких случаях вы выберете RPC, в каких REST, а в каких MQ?

Если ответ на этот вопрос у вас вызывает затруднения, загляните в мой небольшой ЛикБез на тему.

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

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

Думаю, мало кто стал бы спорить, что передовые проекты индустрии разработки программного обеспечения, IT отделы корпораций, в своей работе используют инкрементально-итерационные подходы. Со временем, Agile оброс горой идеализма и шарлатанства: коучи, менторы, мотиваторы — случайные люди, рассказывают о том, как нужно поверить в схемки и диаграмки, чтобы проникнуться общей целью.

Цель данной статьи — поставить идеалистичное отношение к Agile с ног на голову — материалистически объяснить, когда Agile работает, как именно работают те или иные ценности и принципы; какой Agile идеалистический, а какой материалистический.

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

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

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

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

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

Год назад Максим Аршинов (marshinov) выступил с докладом "Быстрорастворимое проектирование". Отличный доклад, харизматичный спикер, полезные материалы в конце. Этот доклад изменил моё понимание того что я делал — кто из нас не пытался интуитивно применить pipeline-архитектуру? А тут ещё элегантные решения, помноженные на DDD! С этого начался мой путь евангелиста предметно-ориентированного проектирования.

Скоро DotNext 2019 Moscow. Как всегда, ждём обзора новых фичей, обмена опытом, best practies, архитектурных решений — за это мы все и любим конференции. В списке докладов вокшоп "Блеск и нищета предметной модели", который обратил моё внимание. Цитата со страницы:

Фаулер и Эванс считают анемичную модель антипаттерном. Однако многие кодовые базы, с которыми доводилось работать спикеру, реализованы в стиле «анемичной» модели. Доклад посвящен сравнению сильных и слабых сторон обоих подходов и не очевидным деталям реализации модели предметной области в парадигме ООП и в функциональном стиле.

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