6952
правки
Изменения
м
Нет описания правки
А еще BPMN - сложен, 15 абстракций и 500 графических конструкций. Поэтому для простых задач его использовать не надо, надо использовать Workflow engine, которых много - Temporal, Cadence и так далее. Там всего пара абстракций, и гораздо меньше графических конструкций и для большого количества задач этого достаточно.
=Олег Захарчук. Действительно ли нам не хватает программистов или проблема в архитектурах? =
Я не слушал этот доклад на конференции, был на параллельном треке. Уже позднее, в январе, меня спросили, что я думаю об этом докладе. Я посмотрел презентацию, и мы обсудили его в переписке. Думаю, это будет интересно, поэтому переношу в отчет. Но явно оговорюсь, что впечатление может быть неточным, так как оно основано на презентации, а не на записи доклада.
Резюме обсуждения такое.
* Система, предложенная Олегом, для работы требует наличия сильного архитектора. Он - сильный архитектор, у него - будет работать. У другого - не факт. Можно перефразировать - у каждого архитектора есть предел масштаба, до которого он может заставить такую схему работать, и чем архитектор сильнее - тем больше масштаб.
* Для систем большого размера это применимо? Чем больше масштаб системы - тем выше требования к архитекторам. Вопрос в наличии таких архитекторов в доступе. Для небольших систем тоже может оказаться эффективным, если архитектор есть. А вот на большом масштабе, на мой взгляд, построение единой модели - НЕ решаемая задача. При этом саму модель предлагается описывать через решение задач, даже не через процессы и не через task flow - а этого недостаточно. А на уровне софта по сути предлагается монолит с единой моделью данных - а это получается не изменяемая конструкция, сложные завязки и прочие проблемы монолита.
* Применимость схемы также сильно зависит от возможности считать контекст на время реализации системы реализации квазистабильным. Иными словами, если у нас относительно слабо изменяющаяся область, так что мы можем разработать единую модель и положить ее в БД, разработать приложения, и внедрить их и за это время бизнес-процессы и другой контекст изменятся относительно слабо, так что достаточно будет адаптации - то оно сработает. Темп изменений разный в разных бизнес-областях. Но чем больше область автоматизации (больше предприятие) - тем больше вероятность изменений.
Теперь подробнее обсуждение.
'''Вопрос'''. По-моему у товарища получилось создать подход, при котором создается сразу единая система, а не пытаются создать куски, а потом их согласовать. Максим, ты не считаешь, что если изначально описать систему, а потом её строить, а не создавать куски, а потом их синхронизировать, настраивать обмен и т.п. - это более продвинутый подход?
'''Мой ответ'''. Тут вопрос в масштабах системы. Автор говорит об архитектуре предприятия в целом. Если мы берем большое предприятие (торговую сеть, производство, банк) - то там нельзя обойтись одной системой. Это пробовали в нулевых, все крупные ERP и банковские системы разрабатывались именно в такой парадигме - большая система закрывает все потребности предприятия. Не получилось, на практике все большие ИТ-ландшафты - фрагментарные. Не получилось по двум причинам (а) сложность - система не лезет в головы и (б) трудоемкость - ты не можешь создать такую большую систему в разумные сроки (год-два), это проект лет на 5-7, а значит у тебя фрагментарный ландшафт старого и нового. А раз так - можно и новое делать из разных вещей. Плюс за 5 лет рынок меняется так, что принятые архитектурные решения оказываются не валидными, надо пересматривать, а часть системы уже сделана.
Все эти подходы - из опыта автоматизации управления физическими объектами (ракеты, космос, атомные станции), а физика меняется гораздо медленнее. Хотя и там новые технологии сейчас сильно меняют ситуацию.
А если брать некоторый фрагмент - то все разумно. Так и делают в современном DDD - ограниченный контекст с моделью предметной области на некоторую ее часть, которую сейчас автоматизируют, и сервисы внутри. Сервисы могут быть на общей БД, а могут использовать свои, тут вопрос требуемой масштабируемости и производительности. Товарищ, кстати, живет в старой парадигме, когда мощности БД заведомо хватит.
<!--
Андрей Петушков
Максим, ты не веришь, что:
1. Товарищу удалось создать систему (надсистему), которая позволяет построить модель системы, включающую в себя домены всей системы?
2. И учитывая цельность надстстемы (среды которая позволяет описывать модель), то у модели «автоматически» получаются согласованные между собой домены? И не надо потом согласовывать между собой домены.
Андрей
Андрей Петушков
Я понимаю на примере языков обособление доменных областей (народов), но при укрупнении (при возникновении нации) возникает какой-то доминирующий язык и вот уже нация говорит на одном языке. Но дальнейшее развитие взаимодействий в обществе приводит к необходимости появления языка межнационального общения и одним из таких становится английской язык (как и ряд других).
И по моему при каждом шаге укрупнения сообщества за счет появления общего языка общения появляются у этой системы новые свойства, те которых не было у частей (по моему системный подход это прекрасно об этом, об эмерджентности).
Андрей
Андрей Петушков
Может быть у созданной товарищем системы появилось (в силу эмерджентности) возможность создавать согласованные модели. Модели у которых части (домены) изначально согласованы.
И не надо потом отдельные доменные области согласовывать между собой. И понятно почему эти доменные области не хотят друг другом согласовываться. Т. к. у тех кто проводит согласование нет представления (или возможности описать) систему как единое целое у увязать части системы в единое целое и получить за счет этого новое свойство системы. И согласованность частей это побочный эффект его подхода.
Андрей
Тот кто придумал часы, как устройство измеряющее время, увидел (придумал) и воплотил эту систему. А тот кто не видит системы в корпусе, шестерёнках и винтиках не может их собрать в единое целое.
Андрей
Андрей Петушков
Но если ему показать чертежи единой системы, то он с большой долей вероятности (при умении читать чертежи, при желании напрячь мозг и др.) поймет что из себя представляют часы как единый механизм. И сможет его отремонтировать, улучшить, изменить.
Андрей
Андрей Петушков
Но пока нет понятия о проектировании, нотации для чертежа, линейки (языка для описания чертежа) нет и описания системы в виде чертежа.
И строители храмов делают свои модели в натуральную величину из дерева + они гении в строительстве. Но пока не инженеры. И нет поэтому сопромата, который поможет рассчитать конструкцию заранее, не проводя натурные испытания и другие дорогостоящие мероприятия.
Андрей
Может товарищу всё же удалось создать нотацию для построения моделей сложный сисем как единого целого?
Андрей
Андрей Петушков
Немного отвлеченный вопрос:
Почему в системе уровня предприятия, например, бухгалтерия должна быть написана своя, а не взята промышленная система бухучета (типа 1С) и допилена до нужного состояния, но с учетом понимается как эта система встроена в целое (в модель предприятия)?
Андрей
Андрей Петушков
Я довольно много лет проработал в строительной отрасли (18 лет). И видел как проектируются заводы (в частности ГОКи (горные обогатительные комбинаты)). Каждый ГОК имеет свои особенности и он в этом смысле уникален. Но чаще всего берутся существующие системы техпроцесса ГОКа и на него расставляется стандартное оборудование. И проектирование ГОКа идет очень поэтапно, но сразу создаются образ будущего ГОКа (например, на стадии ТЭО (но там не только экономика описывается, не смотря на название документа), а всё предприятие в целом.
А потом на каждом шаге, в том числе при строительстве (воплощения системы в «металле»), идет изменение проекта, но при этом есть рамка (образ будущего ГОКа) и она позволяет удержать целостность и непротиворечивость системы.
Андрей
А я сколько слушаю про архитектуру программных решений, не вижу такого же подхода.
Андрей
При этом заимствование из области строительства в области ИТ уже было, когда появилась идея паттернов.
Андрей
Андрей Петушков
Я не понимаю почему ИТ не продолжают заимствовать идеи и подходы (теперь уже в проектировании) у строительной отрасли.
12 янв 2023 г., 12:49
Вы отправили
Объяснение разницы между ИТ-разработкой и задачей проектирования (и строительства) самолетов, автомобилей или зданий есть в старой статье Jack W. Reeves. What is software design (1992) http://www.developerdotstar.com/mag/articles/reeves_design.html перевод http://lib.custis.ru/Reeves Основная фишка - что компилятор быстро собирает продукт, поэтому тщательное проектирование становится экономически неоправданным, сильно дешевле делать итерации с выявлением ошибок и отладкой. При этом не просто дешевле по времени, но и заниматься этим могут менее квалифицированные люди - а это очень важно в условиях дефицита кадров, который начался тогда же в 90-х с появлением персоналок и будет еще долго. Да, есть шанс уйти в вечный цикл порождения новых ошибок. Но без этого ты обречен просто НЕ делать.
Система, предлагаемая товарищем - сложна и сильно поднимает требования к квалификации разработчиков. При ней задача создания ERP сложного предприятия становится сопоставима с задачей разработки новой модели самолета или автомобиля. Но больших предприятий, требующих автоматизации - много больше чем создание новых моделей, и каждому нужна относительно уникальная система или конфигурация многих систем.
А еще - в строительной отрасли успешное проектирование идет за счет сопромата (и других теорий) плюс зрелых технологий, обеспечивающих строительство из типовых решений. В ИТ аналога сопромата нет, а технологии незрелые из-за быстрого развития железа. Для уверенного проектирования требуется использовать технологии с TRL не ниже 8 (опыт Боинга), а зрелость фреймворков в мобилках и web - 4-6, они не успевают стабилизироваться.
What Is Software Design? by Jack W. Reeves - developer.*, Developer Dot Star
-->
{{wl-publish: 2022-10-25 14:02:21 +0300 | MaksTsepkov }}