Поймал себя на том, что раз за разом рисую вот уже года два очень похожие архитектуры систем автоматизации самых разных бизнесов и их процессов. Несмотря на эту разницу в "физическом смысле" они приходят в голову практически одинаковыми, и только ближе к моменту непосредственной реализации начинают расходиться из-за особенностей инструмента воплощения, legacy-компонентов и т.д.
Чтобы не объяснять это собственной зашоренностью (что, наверное, недалеко от истины, но не так интересно), пока придумал красивое объяснение, что идеальные системы все одинаковы, и разница между ними лишь в том, насколько далеко пришлось из-за разных непреодолимых без глобальных изменений причин отойти в каждом случае от эталона.
Posts
6 comments:
Существует несколько принципиально не совместимых и примерно равно распространённых подходов, на вскидку: описание данных (Blackboard, Common Bus) vs описание действий (IoC/DI, сервисы). Разве нет?
Существует, конечно, я утрировал. Просто как-то стукнуло, что большинство различий это, так сказать, "не выпуклости, а вогнутости". Т.е. различия в степени неоптимальности, а не в степени оптимальности.
"Все счастливые семьи похожи друг на друга".
А на чем ты это все рисуешь? Какой твой ежедневный инструментарий?
Ничего конкретного, просто любопытно. "Покажи мне твой десктоп, и я скажу, кто ты" :-)
Большая часть в Visio. Некоторое время назад использовал разные среды для разных видов схем - для WF одно, для БД другое и т.д., но в итоге выяснилось, что удобнее всё в одной среде со сменным набором примитивов.
Я, наверное, кстати, не очень удачно сформулировал в исходном посте - я имел в виду, что когда такие разные бизнес-термины, не имеющие, казалось бы, ничего общего, переводишь на термины "данные", "процесс", "регламент", "решение" и т.д., то они становятся во много одинаковыми. А моделей "идеальных данных", например, не так много - и то, почему они получаются в итоге разными - это как раз те "наследственные проблемы". Т.е. отличия чаще бывают в сторону ухудшения, чем улучшения.
Visio значит. Логично для таких задач. Я мало работаю с документами на таком уровне, то немногое, что мне надо перевести в диаграммы, делаю на Enterprise Architect - австралийский софт для UML, но собственно UML-диаграммы я рисую без всяких строгих пуританских правил - не задумываясь сильно об отличии пунктирной линии от сплошной.
Я меньше работаю с макро-уровнем, больше на уровне design-deployment компонент, но тоже замечаю постепенный приход к унификации решений. Раньше, например, много вкладывалось в понятие "транзакция", имея в виду БД-транзакцию. Когда же пишешь распределенные системы, то с этим приходится покончить, и заменять распределенные БД-транзакции на локальные транзакции с возможностью компенсации. Подход к WF оказывается схожим, меняется лишь наполнение.
По поводу основной мысли - тут в трансляции на ITBlogs ещё есть комментарии, если интересно.
Я действительно как-то лихо сформулировал, "широк человек, я бы сузил", с великоватыми амбициями. Но вообще если сформулировать поскромнее, то чем дальше, тем больше мне нравится эта мысль.
Post a Comment