Работа ИТ архитектора – создание хороших абстракций

В сообщении Как сделать хороший API? я высказал предположение, что разработка повторно-используемых компонент (reusable component) достигается за счет разработки достаточно абстрактных методов, лишенных излишней конкретики, исходящей из текущей задачи. В комментариях к сообщению я привел примеры и получил некоторую критику. В действительности, абстрагирование, конечно же, необходимо не столько для построения хороших интерфейсов, сколько для построения хороших систем. Хороший интерфейс – это следствие хорошей объектной модели системы. Системы, имеющую ясную модель данных и одновременно допускающие её расширения посредством настроек пригодны для повторного использования и не требуят для этого дополнительных доработок. Системы сделанные «на злобу дня» таким свойством не обладают.

Если я правильно помню, то Гради Буч называл программы, разработанные по принципу «сели и начали писать», т.е. без предварительного продумывания (проектирования), зубочистками. Для однократного использования и такой метод сойдет. Для построения собачьей конуры необходимо немножко подумать, наверное, даже чертеж набросать. В спроектированную таким образом конуру вторую собаку мы вряд сумеем поселить, но построить еще один экземпляр собачьей конуры по своим наброскам сможем. А вот запрограммировать скворечник так уже вряд ли получится. Одним словом, подход «сели и начали писать» не подходит для корпоративных информационных систем. Чтобы создать повторно-используемую систему надо провести объектно-ориентированный анализ, разработать хорошую иерархию классов и только потом программировать.

Почему же разработчики корпоративных информационных систем, особенно заказных систем, так не делают? Отчасти ответ на этот вопрос дает Алистер Коберн обнаруживший, что людям больше свойственно заниматься изобретением чего-то нового, чем изучением уже существующего. Другую часть ответа мы найдем у Мартина Фаулера в книге «Архитектура корпоративных программных приложений». Значительная часть этой книге посвящена обсуждению того печального факта, что реляционные базы данных не реализуют механизмы наследования. Т.е. разработав иерархию классов, связанных отношением наследования, программист сталкивается с проблемой запихивания экземпляров этих классов в реляционную базу данных. В одних случаях для хранения экземпляров разных классов используется единая таблица, в других случаях – объекты разносятся по разным. Короче, разработчик предпочитает не заморачиваться объектно-ориентированным подходом и начинает не с создания робастой структуры классов, а с написания таблиц в базе данных. Через пару лет корпоративный ИТ ландшафт превращается в зоопарк редких и исчезающих систем. Я, не задумываясь, насчитаю в нашей компании несколько десятков систем, обрабатывающих разного рода заявки. Естественно, каждая из них реализуют для этого свою уникальную структуру данных, логику и уровень представления. Возможно, от разработчиков и не следует ожидать построения хороших абстракции и это задача, которую предварительно должен выполнить архитектор. Ушел подробнее разбираться в Domain-driven design, надеюсь вернуться оттуда с какими-либо ответами