Как я мог припоздниться со своим комментарием? Как так случилось, что описание того, что я вижу собственными глазами, и того, как я это оцениваю, может припоздниться?
Что еще интересно. Этот подход обеспечивает постоянное развитие системы. Мы добавляем в платформу новые механизмы, и они сразу начинают работать для уже существующих объектов (без усилий разработчика приложений или с минимальными усилиями). Например, недавно мы разработали механизм хранения истории данных (версионирования). Так как система знает в общем виде о семантике данных, то разработчику достаточно поставить флажок, что он хочет хранить историю данных конкретного объекта, и платформа обеспечивает все, что нужно, от хранения истории, до визуализации — отображения пользователю истории изменений в виде различных отчетов.
Здорово. А как это выглядит на практике? Речь идёт, например, о конкретном справочнике, или об объекте, который описывается отдельной строкой-записью в этом справочнике?
Пока мы все-таки стараемся удержаться от введения «просто таблиц», чтобы обеспечить чистоту модели и возможность добавлять новую функциональность, опираясь на знание о семантике всех данных. Если каких-то возможностей не будет хватать, то вначале мы все-таки будем рассматривать то, как можно развить состав типов прикладных объектов. Но, конечно, это вопрос дискуссионный и мы будем продолжать про него думать.
Не надо вводить «просто таблицы». Лучше попытаться вести новые типы данных (объекты конфигурации): «НаборДанных» (для хранения самих неструкутрированных изначально данных), «МодельДанных» (для описания принципов хранения: «ключ-значение», «документ», «расширяемая запись» и т.д. и т.п.) и «РегистрМетаданныхНаборовДанных» (для описания конкретных обрабатываемых в системе данных). Для решения каждой задачи создаётся свой набор данных, выбирается для него модель, формируется своя схема данных, которая отражается в регистре. Возможно, здесь потребуется принципиально новый объект конфигурации, вроде того, который был нужен Almet'у: справочник со свойствами регистра. Здесь нужна возможность доступа по ключу (по определённой системе «разрезов»), но и возможность ссылки на объект справочника. Получается, что мы, как бы, сначала заглядываем к регистр (со связкой ключей-измерений), чтобы узнать уникальный линейный код объекта, и уже из простого линейного справочника берём всё остальное.
Таким образом, возможности, которые предоставляет в готовом виде платформа 1С: Предприятия и то повышение уровня абстракции, которое ценится прикладными разработчиками, во многом опираются именно на набор типов прикладных объектов. Это является одним из наиболее существенных отличий 1С: Предприятия от других средств разработки и одним из главных инструментов, обеспечивающих быструю и унифицированную разработку.
А кто они, конкуренты? Тут одно из двух: либо конкурентов нет, потому как 1С — практически единственная компания, которая использует подход, основанный на типологии прикладных объектов, либо такой подход используется другими компаниями, но в других областях, и, поэтому, прямой конкуренции не получается. Выбранный подход кажется вполне естественным. Вроде бы, все должны заниматься этим. Может быть, всему виною ниша, выбранная 1С, и заблуждение большинства пользователей и разработчиков, что подход 1С — это удел только учётных систем? Ведь, самый главный вопрос разработки программного обеспечения — это то, какова модель управления данными. Если есть подход у правлению, то он общезначим и относится ко всем случаям и ситуациям. ЯТД.
Может быть, это и хорошо. Определённые ограничения на действия программиста должны обеспечить целостность конструкции. Другое дело, что это оборачивается не такой эффективностью вычислений, какой можно было бы добиться при помощи явного составления прямых запросов к БД и применения оптимизации. За всё приходится платить.
Но!
Всегда есть вероятность того, что при ином построении конфигурации какие-то вещи станет выполнять проще. Возникает вопрос: а что это за задача такая, где необходимо переписывать содержимое регистра?
Да, 1С специально предназначен для для разработки прикладных учетных программ. Хотя, если смотреть на продукты 1С, то становится ясно, что на базе одной и той же технологической платформы можно создавать конфигурации для довольно широкого круга задач. Довольно много вещей хорошо укладывается в «прокрустово ложе» заданных объектов конфигурации (справочников, документов, регистров, обработок).
Ваш вопрос относительно справочника со свойствами регистра обоюдоострый.
С одной стороны, всё это упирается в необходимость менять технологическую платформу. Это возможно. Либо нужно вводить дополнительный уровень абстракции, чтобы иметь собственный «конфигуратор» для технологической платформы. Либо существенно дополнить список допустимых объектов теми объектами, которые естественным образом возникают при решении задач, отличных от задач учёта. Состав объектов конфигурации завязан на учётные задачи, но работу по выявлению новых объектов конфигурации можно продолжить и довести до своего логического конца. Но, боюсь, это приведёт к необходимости делать такую продвинутую технологическую платформу частью операционной системы.
Представьте, что будет, если сделать операционную системы чем-то вроде 1С. Это будет означать, что прикладные программисты будут иметь дело только с объектами конфигурации (им не надо будет иметь дело даже с файлами, если операционная система сама будет документно-ориентированной!).
С другой стороны, Ваше желание совместить в одном объекте разные функции разрушает сам подход к организации объектов конфигурации. Смысл подхода заключается именно в том, чтобы каждый объект решал свою задачу. Если хотите, то тут возникает что-то вроде ортогонализации Грамма-Шмидта, которая позволяет перейти от любой линейно независимой системы векторов к ортонормированной системе, в которой скалярные произведения записываются наиболее просто без смешения разноименных элементов. Если бы кто-нибудь сумел проделать аналогичный процесс в программировании, то мы могли бы собирать любые приложения из кубиков-компонентов.
Некоторые ученые считают, что если уменьшить содержание углекислого газа в атмосфере, то снимется парниковый эффект. Дело, однако, в том, что парникового эффекта на самом деле не существует. По мнению профессора Географического факультета МГУ Сергея Павловича Горшкова, все парниковые гипотезы не учитывают разницу между радиационной и тепловой передачей энергии. На самом деле получается не тепловая подушка, а рассеяние, диссипация энергии.
Тепловая машина Земли работает на солнечной тяге. Солнце дает свет и тепло. Эта энергия, попадая в атмосферу, нагревает воздух и поверхность нашей планеты. Это радиационный перенос за счет невидимого длинноволнового излучения. Часть этого излучения отражается поверхностью уже в инфракрасном диапазоне. И, согласно теории парникового эффекта, эта отраженная энергия оказывается в ловушке. Как если бы солнечный зайчик попал в бесконечную зеркальную галерею. Получается, что в нашей теплице-планете нет никакого проветривания – она нагревается и нагревается. Так думают сторонники Киотского протокола. Однако атмосферный воздух перемешивается подобно кипящей воде в кастрюле. Механизмы переноса тепла в атмосфере отличаются от оранжереи.
Сверху вниз, от более холодной атмосферы к более теплой поверхности Земли, не приходит тепло. Оно задерживается внизу только в тех случаях, когда сверху воздушная среда больше нагрета, чем подстилающая поверхность. Но это отдельные инверсии. Они не делают атмосферу сплошь более теплой вверху. Попробуйте подняться в горы, например, куда-нибудь в Гималаи. Вам будет там тепло? Там ледники, там снега. Вы знаете, какой градиент в Альпах? Примерно ноль семь градуса на сто метров. Поднимаетесь на тысячу метров – у вас температура падает на семь градусов, а на несколько тысяч – вы сами понимаете, сколько. Поэтому там ледники.
Ледники наступали и отступали в разные эпохи. Когда-то уровень океана был на 120 метров ниже – вся вода лежала на суше в виде ледников. Но тающие на наших глазах снега Килиманджаро стали одним из поводов бить тревогу. Огромные усилия определенных групп ученых привели к тому, что правительства большинства развитых стран согласились: с влиянием человека на климат что-то надо делать. Однако не страдает ли человечество манией величия?
В отношении углекислого газа надо соразмерять техногенный вклад человечества, все эти машины, фабрики, заводы, которые выбрасывают большое количество углерода, с природным, который существует постоянно, всегда был и всегда будет. Это окисление органического вещества и бактериальное, и другое, естественное. Это вулканическая деятельность, в частности, на суше, где один вулкан может дать за год больше, чем все человечество со всеми его фабриками, вместе взятыми. Кстати, как показывают исследования, сейчас атмосфера и океан недонасыщены углекислотой.
Как же так, спросите вы? Во всем мире сегодня идет борьба с выбросами углекислого газа. Однако данные, полученные в результате изучения древнего климата, показывают, что тысячи лет назад, когда ни о какой хозяйственной деятельности человека речи не шло, в атмосфере Земли было огромное количество углекислого газа, возникшего естественным путем. Заставили задуматься ученых и образцы ископаемого льда, добытые в Антарктиде.
Известный исследователь Антарктиды, директор Института географии РАН, академик Владимир Михайлович Котляков установил, что в периоды оледенений и межледниковья температура на поверхности Земли изменялась на 6-8 градусов. Когда были построены графики температуры и содержания парниковых газов во льду, то оказалось, что они шли параллельно. То есть когда тепло, тогда больше парникового газа, когда холодно – меньше. Детальные наблюдения в Антарктиде также показали, что в отдельные периоды геологической истории нашей планеты парниковые газы были первичными, а потепление было вторичным. Однако в большей части случаев сначала становилось теплее на Земле, а потом, с некоторым опозданием, увеличивалось количество парниковых газов. Поэтому все не так просто, как мы это себе представляем. Как правило, сначала повышалась температура на поверхности нашей планеты, бурно развивалась жизнь на суше и в океане. Но растения и животные не только поглощают кислород, но и выделяют при дыхании углекислый газ. Одна растительность на суше «надышать» углекислоты может довольно много.
Просто оставлю здесь отрывок из книги Александра Городницкого «Тайны и мифы науки. В поисках истины»:
В чем же причина оледенений, которые охватывали нашу планету в самые разные геологические периоды? Какова их природа?
На этот счет существуют разные точки зрения. Прежде всего, ученые ищут научные обоснования в изменении теплового облучения со стороны Солнца, так называемой инсоляции. Считают также, что на это влияет изменение оси вращения Земли относительно среднего положения, так называемые прецессии оси вращения Земли. Можно искать причину также в эндогенном тепле, которое имеет две формы переноса. Одна – это кондуктивный теплоперенос, когда нагреваются верхние слои нашей планеты. Вторая – конвективный теплоперенос, когда тепло распространяется вместе с нагретым веществом, например, вулканизм.
Причиной оледенения может явиться усиление эксплозивного вулканизма. Из геологической истории Земли хорошо известно, что крупные вулканические извержения, которые происходили на памяти человека, запыляли, засоряли стратосферу пылью, а главное, окислами серы, которые превращались в мельчайшие капельки серной кислоты, и тем самым экранировали Землю. Уменьшалась солнечная радиация. Серия таких извержений, подобных, например, знаменитому извержение Кракатау могла привести к началу оледенения.
Оледенение – не результат извержения одного отдельно взятого вулкана. Это результат массового вулканизма, это длительный период, когда выбрасывается огромное количество пепла в атмосферу. Ледниковые щиты имеют одну особенность: появившись раз, они не только сохраняются, но и сами себя поддерживают, да еще и расширяются. Поверхность ледника белая, поэтому она очень хорошо отражает солнечные лучи. В результате резко падает количество тепла, которое доходит до поверхности Земли. Большая часть тепла, которое приходит от Солнца, отражается ледниками. Климат ухудшается. Ледник растет. Потом тучи пепла рассеивались, снова начинала поступать солнечная радиация на поверхность Земли, и ледники начинали отступать. Довольно быстро, кстати сказать… Чем меньше площадь, отражающая солнечное тепло, тем теплее на Земле, что вызывает новое таяние ледника.
Как считает главный научный сотрудник Геологического института РАН доктор геолого-минералогических наук профессор Николай Михайлович Чумаков, активизация вулканизма на Земле приводит к концу ледникового периода. Известно, что самый теплый период был в позднем мезозое, примерно 80 миллионов лет назад. Тогда на поверхности Земли была максимальная вулканическая деятельность. С того времени у нас идет потихоньку сползание температуры, похолодание. Сейчас температура Земли понизилась примерно на 3 градуса. У профессора О.Г. Сорохтина была совершенно иная точка зрения на причины оледенения. Связывал он их не столько с вулканической деятельностью, сколько с изменением атмосферного давления. Бактерии поглощают азот из воздуха. В результате давление воздуха уменьшается, что в свою очередь приводит к понижению температуры. Процесс этот будет продолжаться и дальше до тех пор, пока метаболизм азот-поглощающих бактерий не будет способен извлекать азот из воздуха. Однако этот уровень, который благоприятен для бактерий, может быть неблагоприятен для высших существ, в том числе и для человека.
За время жизни Земли содержание азота в ее атмосфере уменьшилось примерно наполовину, а чем ниже давление атмосферы, тем холоднее на поверхности Земли. Очевидно, что с этим и связано общее похолодание климата. Согласно расчетам О.Г. Сорохтина, сегодня на нашей планете идет небольшое повышение температуры, что мы испытываем сейчас на своей шее, а дальше идет значительное понижение температуры, и нам предстоит довольно суровое оледенение. Это похолодание идет неравномерно, пульсациями, – то немножко потеплее, то похолоднее. Но общий тренд движения климата идет в сторону похолодания. Мы вправе ожидать, что через несколько тысяч лет наступит новый ледниковый период, и он будет значительно более суровый, чем тот, который был 900-630 миллионов лет назад.
Очень поучительно. Особенно в том плане, насколько безосновательными и пустыми оказываются на деле любые гласные возражения против новых перспективных предложений. Если есть рынок, то надо пробовать. Попробовали — получили реальный опыт и либо убедились в своей правоте, либо признали свою неправоту. Всё, что не основывается на практике, призрачно…
К сожалению, в статье никак не рассматривается военный аспект. Где связь, там и особые интересы. Поэтому, истинного виновника торможения технического прогресса (а он, здесь, прямо-таки напрашивается) мы не узнаем никогда. На поверхности будут только коммерческие интересы крупных игроков. Но и эти интересы должны были бы опираться исключительно на конкуренцию, потому как при истинной конкуренции тепло будет всем. Хотя и доставаться это «тепло» будет с трудом.
Крайне любопытно то, что своевременное развитие сотовой связи подтолкнуло бы ранее появление интернета, причём, с гораздо более богатыми возможностями, чем те, которые мы имеем сегодня. Как минимум, было бы довольно рано осознано, что для организации эффективного сетевого взаимодействия нужен постоянный трафик и распределённая семантическая база знаний. Вместо этого, мы имеем Сеть, основанную на противоположном принципе (принципе минимизации трафика), на ворохе технологий, крайне небезопасную и… сбойную.
В мире, где право решающего голоса находится за военными и спецслужбами, любое развитие каких-либо технологий будет всячески сдерживаться и направляться по самым окольным путям. Данная статья наглядно показывает существование прямых путей, пройдя по которым человечество смогло бы получить немало плодотворных результатов.
Любопытно было посмотреть на отрывок, предоставленный на сайте издательства. Там представлено начало главы 12 («Интеграция посредством обмена сообщениями»).
1. Глава начинается с раздела «Загружаемые примеры кода для этой главы», но к этому разделу относится только первый абзац. Затем идёт нормальное введение в главу. Почему так сделано?
2. Далее, начинается, собственно, описание шины сообщений: «Если в системе имеется единственный централизованный компонент, отвечающий за отправку всех сообщений, вся система может обрушиться, если этот компонент прекратит работу». Наверное, книга очень толстая. 832 страницы! Иногда кажется, что объём можно сократить, делая небольшие введения, чтобы не объяснять в разных местах книги то или иное соображение.
3. Также имеется ссылка на рисунок: «Шина сообщений обеспечивает коллективную работу всех частей, как показано на рис. 12.1.». Какой смысл в этом рисунке? Между прочим, он занимает место, но совершенно ничего не добавляет к сказанному в тексте, и, уж точно, не показывает, как именно шина сообщений обеспечивает коллективную работу, поскольку на рисунке показаны только сами связи. Картинка имела бы смысл, если бы на ней изображались какие-то важные детали реализации.
4. Автор(ы) пишут, что «Централизованный компонент, принимающий и рассылающий все сообщения, называют брокером сообщений (message broker), или просто брокером». Интересно, рассказывают ли авторы в своей книге о CORBA? И, если шире ставить вопрос, что они говорят о предшествующих попытках предложить что-то вроде предметно-ориентированного подхода?
5. Также, имеется любопытное примечание:
Как упоминалось в предыдущей главе, под компонентами в этой главе понимаются отдельные приложения, которые можно распространять и развертывать независимо друг от друга. Вы также можете встретить такие названия, как «автономные компоненты» (autonomous components), «распределенные компоненты» (distributed components), «компоненты, обменивающиеся сообщениями» (messaging components) и даже «микрослужбы» (micro services). К сожалению, сообщество разработчиков пока не нашло точного, однозначного и непротиворечивого названия.
От основополагающей книги ожидаешь, что в ней самой предлагается своя чёткая терминология, устраняющая разнобой и позволяющая понять, чем должен быть компонент на самом деле.
В общем, было бы любопытно как-нибудь прочитать на досуге (которого, увы, пока нет) эту книгу, а потом подумать о том, как её можно было бы написать по другому. и, наверное, гораздо короче. Интересно, что можно написать, например, на двухстах страницах?
Если да, то она описывает возможный подход, каким ом мог бы быть. Безусловно, это очень важно и нужно знать, как можно действовать, если хочется действовать эффективно.
Если речь идёт о том, что успешно используется на практике, то в книге явно не хватает обзора реальных примеров. Причём, тут важны не только положительные примеры («вот, посмотрите, как хорошо получается, если делать всё по уму»), но и отрицательные примеры (в том смысле, что если что-то делается не «по уму», то очень важно выявить конкретный источник проблемы). Хотя (кстати!) важны и отрицательные примеры в прямом смысле этого слова, когда показываются ограничения предлагаемого подхода, о которых надо обязательно знать, чтобы не ждать слишком большего и чтобы следить за тем, чтобы применять подход только при условии его применимости (как в физике: «предположим, что имеется идеальный математический маятник с нерастяжимой нитью и пренебрежимо малым сопротивлением воздуха...»).
Вообще, это должна быть, наверное, настольная книга каждого разработчика (судя по оглавлению). Причём, это должно быть чем-то вроде учебника по специальности «Разработка программного обеспечения». Чтобы из стен учебных заведений выходили грамотные специалисты, владеющие системным мышлением и подходом.
Глава 10 повествует о том, как убедить других в преимуществах DDD и начать применять принципы и приемы этого подхода в своих проектах. Здесь объясняется, почему попытки создать идеальную модель предметной области не так ценны для создания качественного программного обеспечения, как исследования и эксперименты.
Ключевой момент книги, да и всей разработки программного обеспечения!
Попытка создать идеальную модель превращает практика -программиста в созерцателя, но ошибочно трактуемые и ошибочно проводимые эксперименты рискуют привести к не гибким системам. Как соблюсти баланс между теорией и практикой? Постановка этого вопроса, правда, не учитывает следующих обстоятельств: во-первых, кто мешает делать теоретические изыскания параллельно с экспериментами; во-вторых, что мешает различным группам разработчиков объединять результаты своих теоретических изысканий; и, наконец, в-третьих, если, всё-таки, идеальная модель существует и является достижимой, то не означает ли это потенциальную возможность создания универсальной библиотеки компонентов?
Таким образом, главная проблема любого предметно-ориентированного анализа заключается в том, что этот анализ всё время приходится начинать заново. И каждая компания делает это самостоятельно один на один с клиентами. Опыт этого анализа и результаты этого анализа оказываются недоступными широкой общественности. (Кроме как в виде отдельных статей для специалистов.) А если обобщить накопленный опыт, то, наверное, можно было бы построить некую единую для всех концептуальную модель, и тогда все разработчики будут действовать в едином адресном пространстве и уже к началу разработки будут иметь существенный задел.
P.S. Вот, по моему совершенно скромному мнению, есть одна существенная проблема: реализация всех элементов системы на одном и том же уровне абстракции. Например, если делается приложение, то пользовательские классы находятся там же, где и базовые классы, реализующие числа, строки, списки, очереди, файлы и и.т.д и т.п. Между тем, кажется очевидным, что Вы должны создать, сначала, некую инфраструктуру, чтобы ввести понятие «программного объекта» (основного объекта, с которым Вы будете дальше работать в приложении), а это значит, что Вы никогда не будете использовать структуры для представления отдельных записей таблиц баз данных, зато Вы всегда будете иметь под руками метаданные, позволяющие Вам задавать локальные проверки обрабатываемых данных и то, что именно должно отображаться в пользовательском интерфейсе.
Другая сторона вопроса — это то, что можно назвать «безИсходным программированием» (без исходников). Если бы программы позволяли бы создавать свои же собственные исходники, то процесс модернизации программного обеспечения существенным образом упростился бы. Например, было бы достаточно иметь в операционной системе компилятор, конфигуратор, приложение и кодовое представление новых требований (фич), то, «распечатав» программу в конфигураторе и осуществив слияние «распечатки» с новыми требованиями, можно было бы пропустить результат через компилятор и получить новую версию приложения, учитывающую более детальную схему предметной области.
И, последнее. Важнейший источник проблемы проектирования программных систем заключается в том, что приложения создают сразу на целевом языке программирования. Между тем, начальное (проектное) состояние приложения должно существенно отличаться от конечного продукта. Условно говоря, конечный программный продукт должен получаться в результате «распечатки» из-под проекта той же системы. При этом, вовсе не обязательно, чтобы язык реализации проекта совпадал с языком реализации конечного приложения. Скорее, наоборот, каждый язык программирования должен определяться кругом решаемых задач…
P.P.S. Что-то я очень много написал! Остановлюсь. А то в ответ на одну книгу придётся написать другую. Хотя, да, было бы крайне любопытно (если будет возможность почитать сам книгу), детально проанализировать её на страницах Хабра. Но что, уж точно, не помешало бы, так это снабдить книгу толстенным томом с описанием конкретных примеров и с указанием как ошибок, так и достижений.
Всё очень интересно. Но! Ужасно хочется попробовать сделать что-нибудь такое самому.
P.S. Очень приятно, что мои подозрения оправдываются. Например, Вы пишете:
В последнее время разделение методов интерфейса (CQS), а впоследствии и самих интерфейсов на Query/Command стало популярным веянием в разработке архитектуры приложений.
Не можете пояснить что это такое?
Но в Magento CQRS применяют не из-за популярности, а из-за того, что для нас иногда это единственный способ построить гибкое расширяемое (адаптирование к специфическим потребностям) решение с возможностью независимо масштабировать операции Чтения и Записи.
Что означает «масшатбирование операции»? И, если это — единственный способ «построить гибкое расширяемое решение», то не должен ли этот способ стать повсеместно используемым? И почему этот способ не использовали раньше (если не использовали)?
Элементы CQRS у нас появились достаточно давно, когда мы задавались вопросом как масштабировать модель данных EAV (entity-attribute-value) для операций чтения и вводили индексные агрегационные таблицы для этого.
Это нужно для очень много чего, включая и обработку медицинских данных.
P.P.S. Я давно хотел сделать складскую программу (в качестве виртуального «задания на собеседованиях»), а тут ещё и в комментариях к статье на Хабре про ERP-системы речь зашла о складских системах. А тут Ваша статья! Будет крайне любопытно обогатиться полезным опытом. Спасибо.
Из центра на данный момент башня не видна с земли.
Вы хотите, чтобы я (например) специально для Вас выложил здесь (кстати, а как здесь можно вставлять картинки?) фотографии прямо «с земли»?
Лахта-центр уже давно видно с Дворцовой набережной. Если прогуляться от Зимнего Дворца (почти от Дворцового моста, начиная где-то с угла Зимнего Дворца) до Гагаринской улицы (быв. улица Войнова), то Лахта-центр будет плавно скользить на фоне Петропавловской крепости. Причём, если стоять в створе Зимней Канавки, то можно увидеть каким удивительным образом контрастируют башня Лахта-центра и Князь-Владимирский Собор. Я, даже, заметил как башня стала видна из-за домов, если идти уже по Адмиралтейской набережной в сторону Сенатской площади.
Так что, извините, но наша Небесная Линия уже искажена башней Лахта-центра.
Да, люди привыкнут. Но мы ещё посмотрим, как башня будет бликовать в солнечную погоду. В этом смысле, даже, хорошо, что у нас мало солнечных дней. Если, конечно, при строительстве не используется какое-то особое небликующее стекло и об этом нам здесь хорошо напишут.
(Хотя, да, было бы сказочно сделать так, чтобы на расстоянии башню не было видно совсем. Такая избирательная технология «стелс».)
Простите, а в запросе нет синтаксической ошибки? А то таблица b как-то нехорошо «повисает в воздухе». Я забыл точный синтаксис SQL-запросов (запятая в запросах применяется в очень ограниченных случаях), и меня терзают сомнения относительно выполнимости такого запроса.
Но!
Всегда есть вероятность того, что при ином построении конфигурации какие-то вещи станет выполнять проще. Возникает вопрос: а что это за задача такая, где необходимо переписывать содержимое регистра?
Ваш вопрос относительно справочника со свойствами регистра обоюдоострый.
С одной стороны, всё это упирается в необходимость менять технологическую платформу. Это возможно. Либо нужно вводить дополнительный уровень абстракции, чтобы иметь собственный «конфигуратор» для технологической платформы. Либо существенно дополнить список допустимых объектов теми объектами, которые естественным образом возникают при решении задач, отличных от задач учёта. Состав объектов конфигурации завязан на учётные задачи, но работу по выявлению новых объектов конфигурации можно продолжить и довести до своего логического конца. Но, боюсь, это приведёт к необходимости делать такую продвинутую технологическую платформу частью операционной системы.
Представьте, что будет, если сделать операционную системы чем-то вроде 1С. Это будет означать, что прикладные программисты будут иметь дело только с объектами конфигурации (им не надо будет иметь дело даже с файлами, если операционная система сама будет документно-ориентированной!).
С другой стороны, Ваше желание совместить в одном объекте разные функции разрушает сам подход к организации объектов конфигурации. Смысл подхода заключается именно в том, чтобы каждый объект решал свою задачу. Если хотите, то тут возникает что-то вроде ортогонализации Грамма-Шмидта, которая позволяет перейти от любой линейно независимой системы векторов к ортонормированной системе, в которой скалярные произведения записываются наиболее просто без смешения разноименных элементов. Если бы кто-нибудь сумел проделать аналогичный процесс в программировании, то мы могли бы собирать любые приложения из кубиков-компонентов.
К сожалению, в статье никак не рассматривается военный аспект. Где связь, там и особые интересы. Поэтому, истинного виновника торможения технического прогресса (а он, здесь, прямо-таки напрашивается) мы не узнаем никогда. На поверхности будут только коммерческие интересы крупных игроков. Но и эти интересы должны были бы опираться исключительно на конкуренцию, потому как при истинной конкуренции тепло будет всем. Хотя и доставаться это «тепло» будет с трудом.
Крайне любопытно то, что своевременное развитие сотовой связи подтолкнуло бы ранее появление интернета, причём, с гораздо более богатыми возможностями, чем те, которые мы имеем сегодня. Как минимум, было бы довольно рано осознано, что для организации эффективного сетевого взаимодействия нужен постоянный трафик и распределённая семантическая база знаний. Вместо этого, мы имеем Сеть, основанную на противоположном принципе (принципе минимизации трафика), на ворохе технологий, крайне небезопасную и… сбойную.
В мире, где право решающего голоса находится за военными и спецслужбами, любое развитие каких-либо технологий будет всячески сдерживаться и направляться по самым окольным путям. Данная статья наглядно показывает существование прямых путей, пройдя по которым человечество смогло бы получить немало плодотворных результатов.
1. Глава начинается с раздела «Загружаемые примеры кода для этой главы», но к этому разделу относится только первый абзац. Затем идёт нормальное введение в главу. Почему так сделано?
2. Далее, начинается, собственно, описание шины сообщений: «Если в системе имеется единственный централизованный компонент, отвечающий за отправку всех сообщений, вся система может обрушиться, если этот компонент прекратит работу». Наверное, книга очень толстая. 832 страницы! Иногда кажется, что объём можно сократить, делая небольшие введения, чтобы не объяснять в разных местах книги то или иное соображение.
3. Также имеется ссылка на рисунок: «Шина сообщений обеспечивает коллективную работу всех частей, как показано на рис. 12.1.». Какой смысл в этом рисунке? Между прочим, он занимает место, но совершенно ничего не добавляет к сказанному в тексте, и, уж точно, не показывает, как именно шина сообщений обеспечивает коллективную работу, поскольку на рисунке показаны только сами связи. Картинка имела бы смысл, если бы на ней изображались какие-то важные детали реализации.
4. Автор(ы) пишут, что «Централизованный компонент, принимающий и рассылающий все сообщения, называют брокером сообщений (message broker), или просто брокером». Интересно, рассказывают ли авторы в своей книге о CORBA? И, если шире ставить вопрос, что они говорят о предшествующих попытках предложить что-то вроде предметно-ориентированного подхода?
5. Также, имеется любопытное примечание:От основополагающей книги ожидаешь, что в ней самой предлагается своя чёткая терминология, устраняющая разнобой и позволяющая понять, чем должен быть компонент на самом деле.
В общем, было бы любопытно как-нибудь прочитать на досуге (которого, увы, пока нет) эту книгу, а потом подумать о том, как её можно было бы написать по другому. и, наверное, гораздо короче. Интересно, что можно написать, например, на двухстах страницах?
Если да, то она описывает возможный подход, каким ом мог бы быть. Безусловно, это очень важно и нужно знать, как можно действовать, если хочется действовать эффективно.
Если речь идёт о том, что успешно используется на практике, то в книге явно не хватает обзора реальных примеров. Причём, тут важны не только положительные примеры («вот, посмотрите, как хорошо получается, если делать всё по уму»), но и отрицательные примеры (в том смысле, что если что-то делается не «по уму», то очень важно выявить конкретный источник проблемы). Хотя (кстати!) важны и отрицательные примеры в прямом смысле этого слова, когда показываются ограничения предлагаемого подхода, о которых надо обязательно знать, чтобы не ждать слишком большего и чтобы следить за тем, чтобы применять подход только при условии его применимости (как в физике: «предположим, что имеется идеальный математический маятник с нерастяжимой нитью и пренебрежимо малым сопротивлением воздуха...»).
Вообще, это должна быть, наверное, настольная книга каждого разработчика (судя по оглавлению). Причём, это должно быть чем-то вроде учебника по специальности «Разработка программного обеспечения». Чтобы из стен учебных заведений выходили грамотные специалисты, владеющие системным мышлением и подходом.
Ключевой момент книги, да и всей разработки программного обеспечения!
Попытка создать идеальную модель превращает практика -программиста в созерцателя, но ошибочно трактуемые и ошибочно проводимые эксперименты рискуют привести к не гибким системам. Как соблюсти баланс между теорией и практикой? Постановка этого вопроса, правда, не учитывает следующих обстоятельств: во-первых, кто мешает делать теоретические изыскания параллельно с экспериментами; во-вторых, что мешает различным группам разработчиков объединять результаты своих теоретических изысканий; и, наконец, в-третьих, если, всё-таки, идеальная модель существует и является достижимой, то не означает ли это потенциальную возможность создания универсальной библиотеки компонентов?
Таким образом, главная проблема любого предметно-ориентированного анализа заключается в том, что этот анализ всё время приходится начинать заново. И каждая компания делает это самостоятельно один на один с клиентами. Опыт этого анализа и результаты этого анализа оказываются недоступными широкой общественности. (Кроме как в виде отдельных статей для специалистов.) А если обобщить накопленный опыт, то, наверное, можно было бы построить некую единую для всех концептуальную модель, и тогда все разработчики будут действовать в едином адресном пространстве и уже к началу разработки будут иметь существенный задел.
P.S. Вот, по моему совершенно скромному мнению, есть одна существенная проблема: реализация всех элементов системы на одном и том же уровне абстракции. Например, если делается приложение, то пользовательские классы находятся там же, где и базовые классы, реализующие числа, строки, списки, очереди, файлы и и.т.д и т.п. Между тем, кажется очевидным, что Вы должны создать, сначала, некую инфраструктуру, чтобы ввести понятие «программного объекта» (основного объекта, с которым Вы будете дальше работать в приложении), а это значит, что Вы никогда не будете использовать структуры для представления отдельных записей таблиц баз данных, зато Вы всегда будете иметь под руками метаданные, позволяющие Вам задавать локальные проверки обрабатываемых данных и то, что именно должно отображаться в пользовательском интерфейсе.
Другая сторона вопроса — это то, что можно назвать «безИсходным программированием» (без исходников). Если бы программы позволяли бы создавать свои же собственные исходники, то процесс модернизации программного обеспечения существенным образом упростился бы. Например, было бы достаточно иметь в операционной системе компилятор, конфигуратор, приложение и кодовое представление новых требований (фич), то, «распечатав» программу в конфигураторе и осуществив слияние «распечатки» с новыми требованиями, можно было бы пропустить результат через компилятор и получить новую версию приложения, учитывающую более детальную схему предметной области.
И, последнее. Важнейший источник проблемы проектирования программных систем заключается в том, что приложения создают сразу на целевом языке программирования. Между тем, начальное (проектное) состояние приложения должно существенно отличаться от конечного продукта. Условно говоря, конечный программный продукт должен получаться в результате «распечатки» из-под проекта той же системы. При этом, вовсе не обязательно, чтобы язык реализации проекта совпадал с языком реализации конечного приложения. Скорее, наоборот, каждый язык программирования должен определяться кругом решаемых задач…
P.P.S. Что-то я очень много написал! Остановлюсь. А то в ответ на одну книгу придётся написать другую. Хотя, да, было бы крайне любопытно (если будет возможность почитать сам книгу), детально проанализировать её на страницах Хабра. Но что, уж точно, не помешало бы, так это снабдить книгу толстенным томом с описанием конкретных примеров и с указанием как ошибок, так и достижений.
P.S. Очень приятно, что мои подозрения оправдываются. Например, Вы пишете:Не можете пояснить что это такое?
Что означает «масшатбирование операции»? И, если это — единственный способ «построить гибкое расширяемое решение», то не должен ли этот способ стать повсеместно используемым? И почему этот способ не использовали раньше (если не использовали)?Это нужно для очень много чего, включая и обработку медицинских данных.
P.P.S. Я давно хотел сделать складскую программу (в качестве виртуального «задания на собеседованиях»), а тут ещё и в комментариях к статье на Хабре про ERP-системы речь зашла о складских системах. А тут Ваша статья! Будет крайне любопытно обогатиться полезным опытом. Спасибо.
Лахта-центр уже давно видно с Дворцовой набережной. Если прогуляться от Зимнего Дворца (почти от Дворцового моста, начиная где-то с угла Зимнего Дворца) до Гагаринской улицы (быв. улица Войнова), то Лахта-центр будет плавно скользить на фоне Петропавловской крепости. Причём, если стоять в створе Зимней Канавки, то можно увидеть каким удивительным образом контрастируют башня Лахта-центра и Князь-Владимирский Собор. Я, даже, заметил как башня стала видна из-за домов, если идти уже по Адмиралтейской набережной в сторону Сенатской площади.
Так что, извините, но наша Небесная Линия уже искажена башней Лахта-центра.
Да, люди привыкнут. Но мы ещё посмотрим, как башня будет бликовать в солнечную погоду. В этом смысле, даже, хорошо, что у нас мало солнечных дней. Если, конечно, при строительстве не используется какое-то особое небликующее стекло и об этом нам здесь хорошо напишут.
(Хотя, да, было бы сказочно сделать так, чтобы на расстоянии башню не было видно совсем. Такая избирательная технология «стелс».)
JOIN, говорите? Придётся всё заново изучать. И учиться всю оставшуюся жизнь, не переставая…bкак-то нехорошо «повисает в воздухе». Я забыл точный синтаксис SQL-запросов (запятая в запросах применяется в очень ограниченных случаях), и меня терзают сомнения относительно выполнимости такого запроса.