Обсуждение

Недавно объяснял одному товарищу, что в основе любой системы автоматизации информационных процессов лежит issue tracker. А реализации разных управленческих подходов и зоопарка ERP-модулей это уже сверху, и стоимость их разработки напрямую зависит от проработки общей системы состояний и событий в issue tracking system ядре. Если же изначально делать ядро только для одного подхода или одной ниши (например, CRM), то результат потом дешевле выкинуть, чем модернизировать.

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

Тут ещё такой момент, что и логика внутри приложений может описываться буквально тем же образом, что и логика автоматизируемых ими областей. То есть, логика пользовательского интерфейса приложения, организационные регламенты и случаи вроде замены оборудования удобно описываются одним и тем же набором "кубиков" в графе зависимостей (причём, без сложной для восприятия бюрократии вроде PhysicalObject/FunctionalObject в ISO 15926).

"логика внутри приложений может описываться буквально тем же образом, что и логика автоматизируемых ими областей" -- разве это не DDD? Хотя лавок, в которых принят сейчас domain-driven development буквально 1% от общего числа лавок (это очень, очень оптимистическая оценка). Насчёт бюрократии различия функционального-компонентного и модульного-физического объектов, так само разделение уж общая идея, но я согласен, что в ISO 15926 какая-то лишняя бюрократия (там ступенька между индивидами физическими и информационными не даёт нормально об этом разговаривать).

Нет, не из области хотелок DDD, а буквально. Такое вот моделирование информационных процессов, по аналогии с моделированием физических процессов в Modelica. Если вспомнить наш редактор, в котором любая из созданных View на некоторое время могла быть установлена в качестве current_view, то в информационном плане это мало отличается от установки "физического" насоса в качестве "функционального".

Я как-то не очень заметил, чем сказанное отличается от того, что я сказал. Мы, вероятно, очень по-разному понимаем и DDD и различия функционального/компонентного/работающего объекта и модульного/изготавливаемого объекта -- установка там типовая операция, плюс замечание что про фукнциональный объект нужно думать не как про тип/класс/абстрактный объект а как про физический объект -- для модульного объекта это очевидно, а для функционального объекта просто постулируется (как писал Mathew West -- инженеры не поймут-с, если будет по-другому, что бы ни говорили об этом учёные-онтологи).

Мне кажется, что понимание сходное, но предмет разный. DDD это некий approach на старых технологиях, а мой интерес в сфере языковых решений. В Modelica можно промоделировать работу насоса, но замену насоса уже нельзя. А я занимаюсь такой штукой, где можно. Не на уровне "следуйте методике", а на уровне простого написания исполняемой спецификации.

Про языки абстрактно говорить нельзя. Нужны примеры кода на бочку.

Примеры будут с публикацией технологии. А пока можно смотреть существующие системы учёта зависимостей. Например, в Modelica, Verilog и VHDL.