Это так делается (опять же из практики моих команд, которые в псевдокоде проектируют): псевдокод сам пишется на русском, но по факту это классы на каком-нибудь JS, и есть кнопка «скомпилировать и запустить».
В классах уже на нормальном языке прописаны правила и «загоняние экземпляров классов в графовую бд neo4j».
А в конце кода функции проверки, которые делают нужные проверки к модели через запросы к этой neo4j и выдают прямо отчет ошибок модели. Ну это помимо классического «не скомпилировалось - значит ошибка где-то в модели».

Проверки соответственно любые: требование поменялось - по зависимостям пройтись; целостность чего-то; у каких функций нет модулей и т.д.; и самое главное - проход по дереву и графу который без графовой бд вообще ногу сломишь проверки делать, а запрос к графовой БД любой студент или консультант))); и покажи мне все серверы на которые смотрят серверы на которых стоит инстанс Oracle на который смотрят Sharepoint версии не более xxx, на серверы с которыми установлены патчи такие-то…

Я бы добавил, что у меня есть ощущение что в современной архитектуре связанных и целостных архитектур не бывает… Все так быстро меняется и с разных viewpoint чуть по-разному видится, поэтому разрывы это вообще у нас всегда ок в проектах… Мы эти отчеты расхождений смотрим и просто ставим в своих task teacker либо «ну и ладно» (и это в нашей практике и ок), либо task создаем на устранение (подглядели подход в ITIL Change & Config).

P.S. Здесь я не говорю про критические системы и вообще наверное говорю про какой-то класс, но сейчас он стал большим

Мы это обсуждали в другом чате. Даже не хочется комментировать этот вопрос

Это так делается (опять же из практики моих команд, которые в псевдокоде проектируют): псевдокод сам пишется на русском, но по факту это классы на каком-нибудь JS, и есть кнопка «скомпилировать и запустить».
В классах уже на нормальном языке прописаны правила и «загоняние экземпляров классов в графовую бд neo4j».
А в конце кода функции проверки, которые делают нужные проверки к модели через запросы к этой neo4j и выдают прямо отчет ошибок модели. Ну это помимо классического «не скомпилировалось - значит ошибка где-то в модели».

Проверки соответственно любые: требование поменялось - по зависимостям пройтись; целостность чего-то; у каких функций нет модулей и т.д.; и самое главное - проход по дереву и графу который без графовой бд вообще ногу сломишь проверки делать, а запрос к графовой БД любой студент или консультант))); и покажи мне все серверы на которые смотрят серверы на которых стоит инстанс Oracle на который смотрят Sharepoint версии не более xxx, на серверы с которыми установлены патчи такие-то…

В такой парадигме вообще все становится монолитом. Тот же Google, у которого отсох auth и дальше по цепочке отсохло все остальное - это тоже тогда монолит

Но переписать на go вполне полезно 😂😂

Текст. В целом давно вообще витает что делать все текстом, с связанными и пере используемыми блоками. есть даже ответ  (из архитектуры зданий и инженерии ее реализующей) - тагирование. Но для ИТ все никак и никто, дорого делать тулы, а спрос не очень что бы большой думаю. если посмотреть "гуру" оформления дата сетов табличных, там тоже советую таблицу минимум таблицей, даже строки не отделять цветами. черт возьми при правильном scale выглядит из результаты лучше чем мои попытки настроить таблицу с минимальными границами.

Ну не знаю)) визуальные образы вроде более информативны)

Левенчуку конечно виднее)) но я так точно делать не буду, имею ввиду псевдокод

Возьмём несложную схему. Она может поместиться на одном экране, а её псевдокод на десяти, а может и на ста

Интересно, Левечук сам так давно руками своими делал)

не знаю, по мне как даже половины критериев нет, что нужно. Да и опять все в таблице, я устал от генерации сотого экселя, потому что нет ide, а кто то хочет и такой срез еще. Нужна нормальная IDE для текста и документов. не процессор текстовый. а полноценная ide + фронт вебовский.

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

Это, мне кажется, сильно про привычку и индивидуальные особенности. Как начинающие dba любят картинки, а с некоторого момента быстрее читают DDL. Просто нужен выразительный язык описания.

Это, мне кажется, сильно про привычку и индивидуальные особенности. Как начинающие dba любят картинки, а с некоторого момента быстрее читают DDL. Просто нужен выразительный язык описания.

Не вполне так. Проектирование базы - индивидуальная работа.

Проектирование решения - совместная групповая.

Ну, что ты, проектированием базы тоже коллективная работа. Не меньше чем решения

А кто мешает из текста в глобус? Или из глобуса, текст формировать/редактировать?

Ну так вопрос то в чем: в какой форме хранить данные (чтобы и версии и совместная обработка и вот это вот все) - ну тут вероятно текст, а вот в каком виде пользоваться, тут скорее зависит от задачи (если оценить - то картинка удобнее, если детали реализации и т.п. то код вероятно)