Комментарии 23
Крайне любопытно, что из этого получится. Вообще, давно пора вернуться к ситуации, когда мы, находясь в пределах СУБД (подходящей архитектуры, хотя бы, даже, и реляционной), описываем все свойства и особенности хранимых и обрабатываемых данных, а уже пользовательский интерфейс возводится над этими описаниями. Причём, этот интерфейс может быть на клиенте (один интерфейс на стационарном компьютере, возможно, и с несколькими мониторами, другой — на смартфоне), быть на (банковском )терминале...
Тут речь идёт о способе описании предметной области в таком виде, чтобы разработка и сопровождение ПО было максимально независимо от баз данных в том числе (от пользовательского интерфейса, конечно тоже). В этом случае можно было бы менять СУБД с минимальными изменениями в бизнес логике, а в идеале без изменений.
В этом случае можно было бы менять СУБД с минимальными изменениями в бизнес логике, а в идеале без изменений
В статье много фундаментальных правильных мыслей. Которые являются основой того, где все будет через лет 50. Но этот комментарий просто умножил все на ноль. СУБД это основа из основ. Ваш комментарий можно рассматривать как: Я хочу строить дома с взаимозаменяемым фундаментом, главное чтобы крыша и обои с плиткой в доме не потрескались. Что можно построить с таким архитектурным планом - неизвестно.
Аналогия со строительством устарела уже как минимум на 20 лет, когда Мартином Фаулером был обозначен термин "рефакторинг". Расскажите, пожалуйста, как происходит рефакторинг в строительстве? А в разработке ПО это ежедневная практика для большинстрва проектов. Аналогия со строительством была очень хороша на заре развития ИТ, когда доминировала каскадная модель жизненного цикла разработки ПО.
Что касается СУБД. Дело в том, что вы в своём посте ставите БД на первое место, по сути объявляете её главенство. В современной разработке это уже не совсем так. В DDD, например, речь идёт о хранилище - некоторой прослойке, уменьшающей зависимость от конкретной СУБД и улучшающей возможности тестирования приложений. Ещё пример: брокер сообщений для микросервисов Apache Kafka, который, не являясь СУБД, может выполнять роль хранилища для некоторых задач.
В своей статье я хотел подчеркнуть первостепенное значение бизнес-логики, всё остальное - вторично, в том числе и БД. Именно этот тезис на мой взгляд должен позволить существенно продвинуться в автоматизации разработки. Если получится, то может случиться примерно такая же революция в ИТ, которая была при переходе в написании программ с машинных кодов и ассемблера на универсальные языки программирования.
Основа информационных систем это информация. Информация первична, а алгоритмы вторичны. Бизнес-логика определяется данными, а не наоборот. К тому же, при недостатке информации на входе вы получаете логику, которая плохо аппроксимирует домен и при получении новой информации вы производите рефакторинг (передекомпозицию). Данные переживают и логику и код. При этом я согласен, что СУБД не основа ИС.
Думаю, ваш изначальный тезис ложный. Основа ИС не информация, а обработка информации. Сама по себе информация важна, но без обработки никому не нужна. Даже на статическом сайте информация для отображения у пользователя должна быть обработана. Хотя бы переобразована из HTML на сервере в DOM на клиенте (в браузере), а ещё передана. Или вы эту обработку не считаете? Тогда где граница между "чистой" информацией и её обработкой?
Информацию и данные можно рассматривать лишь как способ сохранять состояние объектов бизнес-логики (предметной области). Однако каким именно образом я буду это делать определяется из конкретной ситуации. Например, если надёжность инфраструктуры будет достаточно высока, можно хранить состояние в памяти компьютера (если её заведомо хватит, конечно), не используя ни СУБД, ни какие-либо другие хранилища.
Аналогия со строительством устарела уже как минимум на 20 лет, когда Мартином Фаулером был обозначен термин "рефакторинг". Расскажите, пожалуйста, как происходит рефакторинг в строительстве? А в разработке ПО это ежедневная практика для большинстрва проектов.
В строительстве рефакторинг, это когда дядю Васю просят поменять трубы, например чугунные на пластиковые, которые проржавели и протекают.
Что касается СУБД. Дело в том, что вы в своём посте ставите БД на первое место, по сути объявляете её главенство. В современной разработке это уже не совсем так. В DDD, например, речь идёт о хранилище - некоторой прослойке, уменьшающей зависимость от конкретной СУБД и улучшающей возможности тестирования приложений. Ещё пример: брокер сообщений для микросервисов Apache Kafka, который, не являясь СУБД, может выполнять роль хранилища для некоторых задач.
Здесь нужно определится. Если вы за "соврменную разработку", тогда она мало имеет отношения к озвученным розовым пони вверху. Если разработка "не современная" то на БД вполне можно переложить функции DDD, схлопнув огромное количество ненужных слоев между UI и DB. Чтобы писать что-то декларативное с контрактами на вашем же скрине c инвариантами.
Можно сформулировать так: если приложение достаточно сложное, разделимо на модули или подсистемы, требует участия хотя бы нескольких команд, а также мы не имеем точной и окончательной постановки, то крайне желательно предусмотреть устойчивость его кода к изменениям (иногда это называют адаптивностью). Для этого можно использовать различные приёмы и методики. При большом объёме уже написанного кода, при попытке что-то поменять в функциональности или добавить новую, изменения придётся проводить через все слои архитектуры, которая для больших приложений важна.
Если упор делается на предметную область и связь с остальными слоями архитектуры автоматизирована, вплоть до генерации, то затраты на изменения можно существенно сократить. Об этом в статье. И эта мысль хорошо перекликается с цитатой из книжки Сергея Тарасова Дефрагментация мозга. Софтостроение изнутри, которая приведена в сообщении от OlegZH ниже.
Если приложение простое и делается одним-двумя разработчиками, то можно и "схлопнуть" - они и так "дожмут" разработку. Пару ночей не поспят, но доделают, если что.
Возможно, я не вполне понял, что вы имели в виду под термином "современная разработка". Если так, то поясните, пожалуйста.
Если упор делается на предметную область и связь с остальными слоями архитектуры автоматизирована, вплоть до генерации, то затраты на изменения можно существенно сократить. Об этом в статье.
Мысль понятна. Вся магия происходит в неком генераторе кода. Конструкторов NoCode/LowCode сейчас сотни на рынке. Но, на мой взгляд, основная проблема что каждый конструктор мечтает стать новой парадигмой программирования, но остается лишь набором шаблонов.
Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами
Это означает, что хорошо поработали системные аналитики. И только уже потом программисты садятся за программный код. Другое дело, что нужно не минимизировать зависимости, а делать их явными и предсказуемыми. Чтобы каждая команда понимала, где у неё вход, а где у неё выход. То, что делает отдельная комаанда — это реализация преобразования, переводящего то, что находится на выходе, в то, что должно находиться на выходе. Теория функциональных систем, однако!
Однако при гибкой разработке (Agile) аналитиков может не быть совсем. За счёт коротких итераций. См. почти любую методологию на базе манифеста Agile, например Scrum, где аналитик опционален. Техника, рекомендуемая в DDD тоже предлагает решение на этот счёт: общий язык, на котором общается команда должен быть языком предметной области, это значит, что просто переводчик с этого языка для разработчиков не нужен. Если, конечно нет других задач для аналитика.
Смысл аналитика в том, чтобы ходить по стройке как дизайнер, мысленно визуализировать что должно примерно получится и ставить задачи прорабам и строителям. Совершенно не понятно причем тут длина итераций и как можно обойтись без аналитика. Эту роль кто-то должен выполнять, если проект в активной фазе строительства.
Аналогия со строительством в настоящее время совершенно неуместна, см. мой комментарий выше.
Длина итераций важна чтобы усилить обратную связь и вовлечённость заказчика в проект. См. Agile и соответствующие методологии разработки ПО, например.
Можно заметить, что на протяжении эволюции ИТ длинна итераций сокращалась. Если каскадную модели можно назвать одной длинной итерацией, которая чаще всего занимала весь период разработки и внедрения проекта, то такие методологии как RUP или MSF, которые пришли на смену, сократили эти итерации, за весь проект их могло быть несколько, и заказчик мог влиять на ход проекта существенно сильнее.
Гибкая разработка и соответствующие методологии ещё сильнее сокращают длительность итераций за счёт отказа от некоторых документов, например ТЗ, спецификаций и др...
Длина итераций имеет значение... :-).
У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы.
Если бы опыт разработки различных программистов можно было бы как-то аккумулировать... На деле получается, что огромное количество программистов постоянно решает одни и те же задачи, но никто не приводит различные решения к общему знаменателю.
Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему.
Здесь, почему-то, хочется что-нибудь процитировать из книжки Сергея Тарасова Дефрагментация мозга. Софтостроение изнутри, но для этого придётся перечитать эту книгу.
Впрочем, одну цитату можно привести уже сейчас:
Рассмотренная выше подсистема состоит из минимального набора слоёв трёхзвенной архитектуры на основе веб-служб. Тем не менее даже в таком минимальном варианте обилие деталей, промежуточных и служебных классов, проекций и преобразований должно дать представление о проблеме сложности современного состояния софтостроения. Одним из способов обхода этой проблемы является описанная технология программной фабрики, несомненно далёкая от совершенства и ограниченная в наборе целевых платформ.
...
Таким образом, соотношение числа строк мета-кода описания модели к коду его реализации на конкретных архитектурах и платформах составляет около 600 к 30 тысячам или 1 к 50. Это означает, что оснащённый средствами автоматизации программист с навыками моделирования на этапе разработки рутинного и специфичного для платформ/архитектур кода производителен примерно так же, как и его 50 коллег, не владеющих технологией гене- рации кода по моделям. Любое внесение изменений в модель тут же приводит в соответствие все генерируемые слои системы, что ещё более увеличивает разрыв по сравнению с ручными модификациями. Наконец, для генерируемого кода не нужны тесты. Производительность возрастает ещё как минимум вдвое.
Даже если принять во внимание, что доля рутинного и прочего инфраструктурного кода по отношению к прикладному, то есть решающему собственно задачи конечных пользователей, снижается с масштабом системы, есть о чём поразмыслить в спокойной обстановке.
Этим идеям лет тридцать (начиналось с т.н. баз знаний... потом попытки изобрести всякие там DSL...), и я всю дорогу наблюдаю за тем, как они при практическом применении превращаются в обычное "база данных + бизнес-логика" :) Привет коллегам по альма-матер.
Салют!
Многие идеи ждали соего воплощения долго, до тех пор, пока не созревали условия. Взять хотя бы парадигму функционального программирования и лямбда-исчисления...
У меня нет уверенности на 100%, что получится, но есть план двигаться в этом направлении. "Дорогу осилит идущий" (с) Кто-то.
К сожалению, в "академической среде" не хватает дискуссионной площадки, где можно было обсудить эту тему. Или я её не нашёл пока.
Императив предметной области при разработке информационных систем