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