Изменения

м
Нет описания правки
А если брать некоторый фрагмент - то все разумно. Так и делают в современном DDD - ограниченный контекст с моделью предметной области на некоторую ее часть, которую сейчас автоматизируют, и сервисы внутри. Сервисы могут быть на общей БД, а могут использовать свои, тут вопрос требуемой масштабируемости и производительности. Товарищ, кстати, живет в старой парадигме, когда мощности БД заведомо хватит.
<!--Андрей Петушковblockquote>'''Вопрос'''. Максим, ты не веришь, что:1. # Товарищу удалось создать систему (надсистему), которая позволяет построить модель системы, включающую в себя домены всей системы? # И учитывая цельность надстстемы (среды которая позволяет описывать модель), то у модели «автоматически» получаются согласованные между собой домены? И не надо потом согласовывать между собой домены.
2. И учитывая цельность надстстемы (среды которая позволяет описывать модель), то у модели «автоматически» получаются согласованные между собой домены? И не надо потом согласовывать между собой домены.
Андрей
Андрей Петушков
Я понимаю на примере языков обособление доменных областей (народов), но при укрупнении (при возникновении нации) возникает какой-то доминирующий язык и вот уже нация говорит на одном языке. Но дальнейшее развитие взаимодействий в обществе приводит к необходимости появления языка межнационального общения и одним из таких становится английской язык (как и ряд других).
И по моему при каждом шаге укрупнения сообщества за счет появления общего языка общения появляются у этой системы новые свойства, те которых не было у частей (по моему системный подход это прекрасно об этом, об эмерджентности).
АндрейАндрей ПетушковМожет быть у созданной товарищем системы появилось (в силу эмерджентности) возможность создавать согласованные модели. Модели у которых части (домены) изначально согласованы.И не надо потом отдельные доменные области согласовывать между собой. И понятно почему эти доменные области не хотят друг другом согласовываться. Т. к. у тех кто проводит согласование нет представления (или возможности описать) систему как единое целое у увязать части системы в единое целое и получить за счет этого новое свойство системы. И согласованность частей это побочный эффект его подхода.АндрейТот кто придумал часы, как устройство измеряющее время, увидел (придумал) и воплотил эту систему. А тот кто не видит системы в корпусе, шестерёнках и винтиках не может их собрать в единое целое.АндрейАндрей ПетушковНо если ему показать чертежи единой системы, то он с большой долей вероятности (при умении читать чертежи, при желании напрячь мозг и др.) поймет что из себя представляют часы как единый механизм. И сможет его отремонтировать, улучшить, изменить.АндрейАндрей ПетушковНо пока нет понятия о проектировании, нотации для чертежа, линейки (языка для описания чертежа) нет и описания системы в виде чертежа.И строители храмов делают свои модели в натуральную величину из дерева + они гении в строительстве. Но пока не инженеры. И нет поэтому сопромата, который поможет рассчитать конструкцию заранее, не проводя натурные испытания и другие дорогостоящие мероприятия.АндрейМожет товарищу всё же удалось создать нотацию для построения моделей сложный сисем систем как единого целого?АндрейАндрей Петушков
Немного отвлеченный вопрос:
Почему в системе уровня предприятия, например, бухгалтерия должна быть написана своя, а не взята промышленная система бухучета (типа 1С) и допилена до нужного состояния, но с учетом понимается как эта система встроена в целое (в модель предприятия)?
АндрейАндрей ПетушковЯ довольно много лет проработал в строительной отрасли (18 лет). И видел как проектируются заводы (в частности ГОКи (горные обогатительные комбинаты)). Каждый ГОК имеет свои особенности и он в этом смысле уникален. Но чаще всего берутся существующие системы техпроцесса ГОКа и на него расставляется стандартное оборудование. И проектирование ГОКа идет очень поэтапно, но сразу создаются образ будущего ГОКа (например, на стадии ТЭО (но там не только экономика описывается, не смотря на название документа), а всё предприятие в целом.А потом на каждом шаге, в том числе при строительстве (воплощения системы в «металле»), идет изменение проекта, но при этом есть рамка (образ будущего ГОКа) и она позволяет удержать целостность и непротиворечивость системы.АндрейА я сколько слушаю про архитектуру программных решений, не вижу такого же подхода.АндрейПри этом заимствование из области строительства в области ИТ уже было, когда появилась идея паттернов.АндрейАндрей ПетушковЯ не понимаю почему ИТ не продолжают заимствовать идеи и подходы (теперь уже в проектировании) у строительной отрасли.12 янв 2023 г., 12:49</blockquote>Вы отправили'''Мой ответ'''. Объяснение разницы между ИТ-разработкой и задачей проектирования (и строительства) самолетов, автомобилей или зданий есть в старой статье Jack W. Reeves. What is software design (1992) [http://www.developerdotstar.com/mag/articles/reeves_design.html перевод Jack W. Reeves. What is software design] (1992) [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 }}