Мы, двуногие без перьев, всегда по чему-нибудь с ума сходим. Сейчас на коне воинствующая политкорректность и всякие Grivance Studies. Но это пройдёт. Нужно спокойно относиться к такой смешной фигне. Очень не похоже на то, чтобы эти заскоки вылились в физическое истребление миллионов граждан, а если так, то и наплевать.
Активизацию всех этих звездостраданий я связываю с тем, что мы попали в эпоху чудовищной глобализации и централизации среды общения. Чтобы понять, что произошло, давайте посмотрим, как оно развивалось в динамике. Совсем в доисторические времена забираться не будем, начнём с появления Веба.
— Web 1.0 — не интерактивные или слабо интерактивные странички. По сути, способ глобального самиздата. Общение в одну сторону: автор -> читатель.
— Web 2.0 — это не про соцсети. Между соцсетями и веб-один-ноль были ещё форумы, коих было миллион. Это уже было многостороннее общение, но тематически/локально/как угодно ещё фрагментированное. Наш любимый Хабр, кстати, веб-два-нольная штука.
— Web 3.0, то есть соцсети, породил динозавров, которых можно пересчитать по пальцам одной руки (ну ладно, двух), которые придавили всех остальных.
В эпоху 2.0 я вполне мог зайти в новостной форум и ацки втопить на тему политики, потом пойти в районный форум пообсуждать прокладку пешеходных дорожек, потом зайти в технический форум порассуждать о синтаксисе JavaScript, и наконец пойти в форум про худлит и выступить там под личиной тётеньки средних лет (почему бы себе не позволить такую невинную шалость?). В нашу прекрасную эпоху 3.0 так не забалуешь. Фейсбук един как наша Единая Россия. Если ты пролайкал посты Навального, твои патриотически настроенные родственники получают в свою ленту серию того, что их выбесит. А товарищи по JavaScript не радуются спаму про дорожки. А маскарад становится вообще немыслимым.
Представьте себе ресторан, который одновременно для всех — и для любителей сочного стейка, и для хардкорных веганов, и для любителей шансона, и для поклонников джаза, и для богатых, и для публики попроще. Все сидят в одном зале, и… ну конечно, всех всё будет нервировать и обижать. Когда мимо компании веганов понесут копчёного поросёнка, они не будут счастливы. Тотальная обиженность всех на всех — прямое следствие мегацентрализации среды общения.
У каждого из нас неизбежно жизнь чётко разделяется по аспектам. То, что уместно среди родственников, неуместно среди коллег. Что уместно среди коллег, неуместно в хобби-сообществе. Что уместно в хобби-сообществе, может расстроить родственников. Речь не о двуличности и каком-то криминале. Просто мы так устроены. Моим хобби может быть сочинение матерных частушек, но среди родственников я могу стопроцентно блюсти нормативность языка. Это не просто вариант нормы, это реальность, свойственная нам от природы.
С приходом 3.0 мне стало очень неудобно. Потеряно много хороших, добрых и продуктивных кусков моей сетевой активности. Люди не лохи, люди разберутся, что глобализованные централизованные среды общения — не сахар с мёдом. Могу предположить, что по прошествии лет все эти фейсбуки-твиттеры-инстаграммы мы будем вспоминать как какую-то глупость, в которую нас не понятно как угораздило играть. И, в конце концов, чёрт возьми, займутся реальными локальными делами, а не страданиями по поводу упадка морали. Война окончится, всем будет спасибо, все будут свободны.
По-хорошему, это надо было бы спросить у автора цитаты, но он, к сожалению, уже давно как умер.
Что касается морали, то мы все прекрасно знаем, что это такое. Только выразить словами не получается. Как только пытаемся подобрать слова, получается какая-то фигня. Имплицитное знание имеется чёткое и ясное, а эксплицитное отсутствует. Вернее, присутствует, но качество… Мне очень понравилось Ваше словосочетание «битва фанфиков».
Здравомыслие есть вещь, распределенная справедливее всего; каждый считает себя настолько им наделенным, что даже те, кого всего труднее удовлетворить в каком-либо другом отношении, обыкновенно не стремятся иметь здравого смысла больше, чем у них есть.
Рене Декарт
Большие данные, т.н. ИИ и экономика внимания вместе сплавляются в ту интересную штуку, которую я повадился называть словосочетанием «социальное скотоводство».
Чем активнее и изощрённее людей загоняют в стойла, тем активнее и изощрённее они этому сопротивляются. Некоторые защитные механизмы срабатывают даже на подсознательном уровне. Могу предположить что соревнование снаряда и брони продолжится. Защита, конечно, победит (человек — самое хитрое, своенравное и изворотливое существо в разведанной части Вселенной), но развивающиеся гуманитарные технологии социального скотоводства нам доставят ещё много неприятностей.
А программирование ради решения бизнес-задачи, которая обычно немножко шире, чем программирование.
Если DDD — это моделирование, то почему оно тогда не DDM? Откуда тогда там слово «дизайн»?
Жаль, что мне так и не удалось донести светлую мысль, что моделирование и дизайн — это совсем разные вещи. Что первое может быть подпроцессом второго, а может и наоборот. Народ привык трактовать понятие «моделирование» глобально, смешивая в одну кучу вообще всё. Даже пример с гвоздём, доской и молотком не помогает, хотя казалось бы куда нагляднее :(
Предметную область вполне бывает полезно моделировать в нотации IDEF0, в которой функции (поведение) — это квадратики, а сущности — всего лишь стрелочки. В EPCшной нотации (aka ARIS) основные квадратики — это события (тоже поведение), а сущности пасутся вокруг основных квадратиков во вспомогательных прямоугольничках с закруглёнными краями.
Можно провести параллель с функциональным стилем в программировании, где функция — это тоже объект.
Вообще, мне кажется, в своей основе DDD — не только и не столько про моделирование, сколько про учёт контекстов при работе с понятийным аппаратом. Весьма здравая, кстати, идея.
Нам бы сейчас не скатиться в схоластику. А то увязнем в рассуждениях о том, является ли капля воды моделью Вселенной, а Луна моделью Солнца.
Давайте немножко посмотрим на примеры, приведённые в докладе. Классический модельный подход подразумевает, что мы должны построить модель предметной области и заложить её в конструкцию создаваемой системы. Допустим, при исследовании задачи у нас нарисовались понятия «Speaker», «Talk», «Event». В нашей модели это у нас классы объектов. Объект — это некая сущность, «живущая» внутри системы, имеющая некие свойства и обладающая неким поведением. То есть в реальном мире спикеры делают толки на эвентах, и внутри программы есть тоже «спикеры», «делающие» «толки» на «эвентах». Считается, что чем точнее объекты программы повторяют (обычно говорят «отражают») поведение объектов реального мира, тем полезнее программа, но это справедливо только для симуляторов. Имитационная модель — да, она как раз предназначена для того, чтобы прогнать ситуацию внутри компьютера, и для имитационной модели действительно важно, чтобы объекты в программе «отражали» объекты реального мира. Теперь ответьте честно, много ли из того, чем приходится лично Вам заниматься, является имитационными моделями в полном классическом смысле этого понятия? Вангую, что примерно 0%. Это очень узкая ниша, хоть и весьма уважаемая.
Даже если заходить на задачу со стороны структуры базы данных, гораздо полезнее оказывается не пытаться своими таблицами воспроизводить реальный мир, а озаботиться поиском ответов на вопросы типа таких:
— Какого рода факты мы желаем хранить в своей базе?
— О чём эти факты? (именно из ответов на такие вопросы у нас появляются entities)
— Как эти факты между собой логически связаны? (здесь у нас появляются constraints)
— Как должен быть организован процесс добавления фактов в базу?
— Какие производные факты мы желаем получать на основе первичных?
(Можно заметить, что здесь у нас базовым понятием странным образом является не «объект», а «факт». Впрочем, ничего удивительного, ещё со времён старика Кодда математической основой баз данных служит исчисление предикатов, которое по своей сути не про объекты, а про факты.)
Если мы занимаемся моделированием, то сразу нас выносит на то, что Speaker имеет фамилию и имя, а Talk имеет дату/время. И мы радостно запихиваем атрибуты в таблички. А потом оказывается, что спикером может быть компания, которая пока не решила, кто конкретно из её сотрудников будет докладываться. А рядом с докладом появляются такие реально отсутствующие в грешном физическом мире вещи, как «отмена», «перенос», «замена» (уведомление об отмене в реальности существует, а сама отмена — как-то не очень). И нам, оказывается, полезно вместо атрибута TalkDateTime таблицы Talks иметь отдельным потоками назначения, переносы, замены и отмены, а TalkDateTime вычислять на их основе.
Когда у нас первичны модели и их объекты, мы обречены вляпаться в не имеющую ни одного до конца нормального решения проблему ORM, об которую вся индустрия убивается уже несколько десятков лет. А если отречься от глупостей (ну или хотя бы снизить уровень догматичной упёртости в них), то можно помочь себе тем, что взглянуть на вопрос с альтернативного ракурса. Например, вместо ORM поиметь ROM. То есть база — это набор фактов, а в набор объектов она транслируется в зависимости от угла зрения. То есть факт «Алексей Мерсон далает доклад про ДДД продолжительностью 1 час» оказывается реляционно-объектно отмэппленым на объекты «Алексей Мерсон», «доклад про ДДД», и ещё на расписание эвента. С какой стороны на набор фактов посмотрели, такой набор объектов получили.
берём какую-то часть реального мира, бизнес-процесса, и превращаем её в код, то есть строим программную модель
Ну, не знаю… Весьма распространённый взгляд на то, чем мы занимаемся, но это никак не уменьшает его ущербность. Чтобы понять, в чём подвох, взгляните на аналогичное рассуждение: берём доску и гвоздь, и превращаем их в молоток, то есть в натурную модель доски и гвоздя. Абсурд ведь, разве нет? Модельерский подход к проектированию систем не менее абсурден, просто его бредовость мы привыкли не замечать.
Моделирование как вспомогательный инструмент мы, конечно, все применяем. Порисовать квадратики со стрелочками в разных нотациях — святое дело. Пользуясь приведённой аналогией, нам при создании молотка полезно понимать, как гвоздь может быть загнан в доску. Но боже упаси буквально переносить модель в программную систему. Программа, предназначенная для удовлетворения каких-то нужд, не является ни самими этими нуждами (точно так же, как молоток не является гвоздём), ни ситуацией удовлетворения нужд. Это самостоятельная сущность. Инструмент. И части этого инструмента совсем не обязаны один-в-один логически мэппиться на предметную область. Что-то, конечно, естественным образом смэппится, но что-то и нет. Это абсолютно нормально.
Мне, например, неоднократно удавалось выкручиваться из сложных ситуаций при помощи дизайна, основанного на метафорах (MDD?). То есть не пытаемся «отразить» в программе сущности реального мира (это всё равно невозможно, потому что реальный мир бесконечно разнообразен, холистичен и постоянно изменчив), а задумываемся над тем, какими инструментами пользователю было бы понятно, как решать его задачи. Текстовый редактор, например, использует метафору (не модель!!!) листа бумаги, мэйл — метафору почтового ящика, файловая система — полки с папками.
И ещё маленький момент. При использовании всяких модных методик дизайна самое главное — не скатиться в Pattern Driven Design. Невозможно думать книжкой готовых рецептов. Думать можно только головой.
Мы с товарищем получили по 100 рублей. Взяли по паре пива по полтиннику за банку. Ему откатился рубль бонусов. Рубль этот заложен в цену пива, потому что пивной ларёк, как известно, деньги не печатает. Банк платит его из своей комиссии. Банк тоже деньги не печатает. Соответственно, пиво дороже того, что оно могло бы стоить на размер комиссии, помноженный на вероятность того, что покупатели расплачиваются карточками. Товарищ, кстати, тоже в проигрыше, но в чуть меньшем (на размер бонуса), чем я.
Неужели в этой примитивной бухгалтерии что-то не понятно? Что здесь доказывать? То, что ларёк деньги не печатает?
В голосовалке про научно-технический прогресс за последние 30 лет отметил вариант «другое», и теперь, видимо, нужно идти по сценарию «свой вариант в комментах».
За последние 30 лет чрезвычайно развились такие прекрасные научные направления как Climate Change Studies, Gender Studies и прочие чудные научные дисциплины. Стартовав с общенаучных и гуманитарных направлений, постмодернизм добрался до физики, и сейчас её уже, говорят, дожёвывает.
По формальным критериям прогресс разогнался до невозможности, но по полезному выхлопу всё в большем количестве областей удивительным образом наблюдается отсутствие присутствия. То есть и ускорился, и замедлился одновременно. По формальным критериям ускорился, а по практической применимости замедлился. Бывает.
В принципе, ничего страшного в этой ситуации нет. Всё равно ведь, как поётся в одной известной песне, an economy based on endless growth is unsustainable.
Допустим, я покупаю пиво за нал. Мой товарищ в той же точке покупает пиво по карте. Товарищу некоторую часть потраченного возвращают бонусами. Вопрос: за чей счёт этот бонусный банкет? За счёт пивного ларька? Неа. За счёт добренького банка? Тоже нет. Выходит, я спонсирую товарищу его пиво. Единственный способ прекратить мне заниматься такой принудительной благотворительностью — самому перейти на безнал. По сути, население мягко загоняют в безнал.
Наличка — это дикая капиталистическая вольница, в которой экономические агенты взаимодействуют, не отчитываясь за каждый чих перед товарищем майором и налоговой инспекцией. Сегодня ты пиво за нал покупаешь, а завтра терроризм международный финансируешь. Не хорошо это. Надо всех загонять в безнал. Кого насильно, кого через жадность до бонусов.
Ссылки — это ерунда. Если ссылку удалить невозможно, то можно уничтожить ресурс, на который она ведёт. Более интересная тема — постить богохульство, призывы к насильственным свержениям конституционных строев, оскорбления всех мыслимых чувств и прочую бездуховность.
Между прочим, гениально. Реактивность без Реакта (и прочих <подставьте название любимого фреймворка>), сразу декларативно на уровне языка разметки. Одна из тех идей, которые десятилетиями лежат незамеченными прямо перед глазами.
Вопрос не в том, существует объект или не существует. И даже не в том, может он существовать или нет (в своё время Кант, который не Кантор, дал простой критерий возможности — возможно всё, существование чего не противоречит самому себе).
По-хорошему, нужно разбираться в том, почему и как так получается, что человеческому сознанию необходимо оперировать объектами, и как в результате этого оно приходит к понятию «объект». Соответственно, нечеловеческое сознание, можно пофантазировать, свободно от наших ограничений, и может оперировать тем, что нашему пониманию недоступно, потому что объектом не является.
Или нет. Объекты — это вообще что за звери такие? Откуда они взялись?
Человек — объект, дождь — объект, «находиться под» — отношение, которое тоже объект. Говорят, что «всё есть объекты», но это бессмыслица. Вводя любое понятие, мы обязаны (и никуда нам от этого не деться) высветить это понятие на фоне того, что под него не подпадает. Понятие «объект» не может быть исключением. Внимание, вопрос: что не является объектом?
Если задачу можно решить просто и дубово, без лишних наворотов и зависимостей от всей необъятной Вселенной, её нужно решать просто и дубово. Решение новичка, накрутившего глупостей и корявостей по незнанию — это, конечно, зло, но и код гения, решившего на простенькой задачке про засабмичивание firstname и lastname продемонстрировать свою невероятную крутизну — зло ни разу не меньшее. И пусть он не тешит себя мыслью про то, что потом его формочку можно будет превратить в полноценный фейсбук. Никто в фейсбук её превращать не захочет. А во что её захотят превратить, он всё равно не угадает. Потому что никто не знает будущего. А кто думает, что знает, у того просто мало опыта.
Даже самый ярый поклонник реакта всё равно хоть один раз в своём проекте, да вписывает гетЭлементБайИД. То есть он по-любому знаком и с ваниллой, и с ХТМЛ, и с ЦСС.
А вот если при изготовлении фигни её автор в порыве вдохновения изобретал свой ни на что не похожий реакт — да, труба дело. Только посочувствовать.
Теперь представьте себе две ситуации:
1. Фигня — самоизобретённый велосипед. То есть не сильно заморачиваясь универсальностью сделали ровно то, что требовалось. Зависимости — только на стандартные библиотеки. Уровень перфекционизма — средненький.
2. Фигня сделана согласно полному комплекту веяний моды. Зависимости уходят в недра npm (как вариант, PyPI или чего ещё, без разницы), и там рекурсивно подхватывают существенный процент наработок сообщества.
Предположим, прошло 10 лет.
В первом случае после некоторого периода ознакомления с конструкцией пациента просто берём и докручиваем требуемое. И средство разработки, и стандартные библиотеки никуда не делись. Если нужно, на просторах Интернета можно найти что угодно, хоть 3-й турбо-паскаль.
Во втором случае оказывается, что используемые пакеты часть заброшены (и уже несовместимы со своими зависимыми), часть потерялись, часть развились так, что не узнать. Бубен в руки и вперёд, пытаемся восстановить состояние состояние инфраструктуры на тот момент, когда фигня создавалась.
В первом случае чтобы разобраться, нужно освежить знания по средству разработки и его стандартным библиотекам. Во втором — по той Джомолунгме барахла, от которого пациент зависим.
С чисто прагматической точки зрения лично я выбрал бы первое. Ну нафиг бегать с бубном вокруг Джомолунгмы.
Активизацию всех этих звездостраданий я связываю с тем, что мы попали в эпоху чудовищной глобализации и централизации среды общения. Чтобы понять, что произошло, давайте посмотрим, как оно развивалось в динамике. Совсем в доисторические времена забираться не будем, начнём с появления Веба.
— Web 1.0 — не интерактивные или слабо интерактивные странички. По сути, способ глобального самиздата. Общение в одну сторону: автор -> читатель.
— Web 2.0 — это не про соцсети. Между соцсетями и веб-один-ноль были ещё форумы, коих было миллион. Это уже было многостороннее общение, но тематически/локально/как угодно ещё фрагментированное. Наш любимый Хабр, кстати, веб-два-нольная штука.
— Web 3.0, то есть соцсети, породил динозавров, которых можно пересчитать по пальцам одной руки (ну ладно, двух), которые придавили всех остальных.
В эпоху 2.0 я вполне мог зайти в новостной форум и ацки втопить на тему политики, потом пойти в районный форум пообсуждать прокладку пешеходных дорожек, потом зайти в технический форум порассуждать о синтаксисе JavaScript, и наконец пойти в форум про худлит и выступить там под личиной тётеньки средних лет (почему бы себе не позволить такую невинную шалость?). В нашу прекрасную эпоху 3.0 так не забалуешь. Фейсбук един как наша Единая Россия. Если ты пролайкал посты Навального, твои патриотически настроенные родственники получают в свою ленту серию того, что их выбесит. А товарищи по JavaScript не радуются спаму про дорожки. А маскарад становится вообще немыслимым.
Представьте себе ресторан, который одновременно для всех — и для любителей сочного стейка, и для хардкорных веганов, и для любителей шансона, и для поклонников джаза, и для богатых, и для публики попроще. Все сидят в одном зале, и… ну конечно, всех всё будет нервировать и обижать. Когда мимо компании веганов понесут копчёного поросёнка, они не будут счастливы. Тотальная обиженность всех на всех — прямое следствие мегацентрализации среды общения.
У каждого из нас неизбежно жизнь чётко разделяется по аспектам. То, что уместно среди родственников, неуместно среди коллег. Что уместно среди коллег, неуместно в хобби-сообществе. Что уместно в хобби-сообществе, может расстроить родственников. Речь не о двуличности и каком-то криминале. Просто мы так устроены. Моим хобби может быть сочинение матерных частушек, но среди родственников я могу стопроцентно блюсти нормативность языка. Это не просто вариант нормы, это реальность, свойственная нам от природы.
С приходом 3.0 мне стало очень неудобно. Потеряно много хороших, добрых и продуктивных кусков моей сетевой активности. Люди не лохи, люди разберутся, что глобализованные централизованные среды общения — не сахар с мёдом. Могу предположить, что по прошествии лет все эти фейсбуки-твиттеры-инстаграммы мы будем вспоминать как какую-то глупость, в которую нас не понятно как угораздило играть. И, в конце концов, чёрт возьми, займутся реальными локальными делами, а не страданиями по поводу упадка морали. Война окончится, всем будет спасибо, все будут свободны.
Что касается морали, то мы все прекрасно знаем, что это такое. Только выразить словами не получается. Как только пытаемся подобрать слова, получается какая-то фигня. Имплицитное знание имеется чёткое и ясное, а эксплицитное отсутствует. Вернее, присутствует, но качество… Мне очень понравилось Ваше словосочетание «битва фанфиков».
Чем активнее и изощрённее людей загоняют в стойла, тем активнее и изощрённее они этому сопротивляются. Некоторые защитные механизмы срабатывают даже на подсознательном уровне. Могу предположить что соревнование снаряда и брони продолжится. Защита, конечно, победит (человек — самое хитрое, своенравное и изворотливое существо в разведанной части Вселенной), но развивающиеся гуманитарные технологии социального скотоводства нам доставят ещё много неприятностей.
Если DDD — это моделирование, то почему оно тогда не DDM? Откуда тогда там слово «дизайн»?
Жаль, что мне так и не удалось донести светлую мысль, что моделирование и дизайн — это совсем разные вещи. Что первое может быть подпроцессом второго, а может и наоборот. Народ привык трактовать понятие «моделирование» глобально, смешивая в одну кучу вообще всё. Даже пример с гвоздём, доской и молотком не помогает, хотя казалось бы куда нагляднее :(
Можно провести параллель с функциональным стилем в программировании, где функция — это тоже объект.
Вообще, мне кажется, в своей основе DDD — не только и не столько про моделирование, сколько про учёт контекстов при работе с понятийным аппаратом. Весьма здравая, кстати, идея.
Давайте немножко посмотрим на примеры, приведённые в докладе. Классический модельный подход подразумевает, что мы должны построить модель предметной области и заложить её в конструкцию создаваемой системы. Допустим, при исследовании задачи у нас нарисовались понятия «Speaker», «Talk», «Event». В нашей модели это у нас классы объектов. Объект — это некая сущность, «живущая» внутри системы, имеющая некие свойства и обладающая неким поведением. То есть в реальном мире спикеры делают толки на эвентах, и внутри программы есть тоже «спикеры», «делающие» «толки» на «эвентах». Считается, что чем точнее объекты программы повторяют (обычно говорят «отражают») поведение объектов реального мира, тем полезнее программа, но это справедливо только для симуляторов. Имитационная модель — да, она как раз предназначена для того, чтобы прогнать ситуацию внутри компьютера, и для имитационной модели действительно важно, чтобы объекты в программе «отражали» объекты реального мира. Теперь ответьте честно, много ли из того, чем приходится лично Вам заниматься, является имитационными моделями в полном классическом смысле этого понятия? Вангую, что примерно 0%. Это очень узкая ниша, хоть и весьма уважаемая.
Даже если заходить на задачу со стороны структуры базы данных, гораздо полезнее оказывается не пытаться своими таблицами воспроизводить реальный мир, а озаботиться поиском ответов на вопросы типа таких:
— Какого рода факты мы желаем хранить в своей базе?
— О чём эти факты? (именно из ответов на такие вопросы у нас появляются entities)
— Как эти факты между собой логически связаны? (здесь у нас появляются constraints)
— Как должен быть организован процесс добавления фактов в базу?
— Какие производные факты мы желаем получать на основе первичных?
(Можно заметить, что здесь у нас базовым понятием странным образом является не «объект», а «факт». Впрочем, ничего удивительного, ещё со времён старика Кодда математической основой баз данных служит исчисление предикатов, которое по своей сути не про объекты, а про факты.)
Если мы занимаемся моделированием, то сразу нас выносит на то, что Speaker имеет фамилию и имя, а Talk имеет дату/время. И мы радостно запихиваем атрибуты в таблички. А потом оказывается, что спикером может быть компания, которая пока не решила, кто конкретно из её сотрудников будет докладываться. А рядом с докладом появляются такие реально отсутствующие в грешном физическом мире вещи, как «отмена», «перенос», «замена» (уведомление об отмене в реальности существует, а сама отмена — как-то не очень). И нам, оказывается, полезно вместо атрибута TalkDateTime таблицы Talks иметь отдельным потоками назначения, переносы, замены и отмены, а TalkDateTime вычислять на их основе.
Когда у нас первичны модели и их объекты, мы обречены вляпаться в не имеющую ни одного до конца нормального решения проблему ORM, об которую вся индустрия убивается уже несколько десятков лет. А если отречься от глупостей (ну или хотя бы снизить уровень догматичной упёртости в них), то можно помочь себе тем, что взглянуть на вопрос с альтернативного ракурса. Например, вместо ORM поиметь ROM. То есть база — это набор фактов, а в набор объектов она транслируется в зависимости от угла зрения. То есть факт «Алексей Мерсон далает доклад про ДДД продолжительностью 1 час» оказывается реляционно-объектно отмэппленым на объекты «Алексей Мерсон», «доклад про ДДД», и ещё на расписание эвента. С какой стороны на набор фактов посмотрели, такой набор объектов получили.
Ой, что-то я слишком много ереси написал… ;)
Немножко вставлю свои пять копеек.
Ну, не знаю… Весьма распространённый взгляд на то, чем мы занимаемся, но это никак не уменьшает его ущербность. Чтобы понять, в чём подвох, взгляните на аналогичное рассуждение: берём доску и гвоздь, и превращаем их в молоток, то есть в натурную модель доски и гвоздя. Абсурд ведь, разве нет? Модельерский подход к проектированию систем не менее абсурден, просто его бредовость мы привыкли не замечать.
Моделирование как вспомогательный инструмент мы, конечно, все применяем. Порисовать квадратики со стрелочками в разных нотациях — святое дело. Пользуясь приведённой аналогией, нам при создании молотка полезно понимать, как гвоздь может быть загнан в доску. Но боже упаси буквально переносить модель в программную систему. Программа, предназначенная для удовлетворения каких-то нужд, не является ни самими этими нуждами (точно так же, как молоток не является гвоздём), ни ситуацией удовлетворения нужд. Это самостоятельная сущность. Инструмент. И части этого инструмента совсем не обязаны один-в-один логически мэппиться на предметную область. Что-то, конечно, естественным образом смэппится, но что-то и нет. Это абсолютно нормально.
Мне, например, неоднократно удавалось выкручиваться из сложных ситуаций при помощи дизайна, основанного на метафорах (MDD?). То есть не пытаемся «отразить» в программе сущности реального мира (это всё равно невозможно, потому что реальный мир бесконечно разнообразен, холистичен и постоянно изменчив), а задумываемся над тем, какими инструментами пользователю было бы понятно, как решать его задачи. Текстовый редактор, например, использует метафору (не модель!!!) листа бумаги, мэйл — метафору почтового ящика, файловая система — полки с папками.
И ещё маленький момент. При использовании всяких модных методик дизайна самое главное — не скатиться в Pattern Driven Design. Невозможно думать книжкой готовых рецептов. Думать можно только головой.
Мы с товарищем получили по 100 рублей. Взяли по паре пива по полтиннику за банку. Ему откатился рубль бонусов. Рубль этот заложен в цену пива, потому что пивной ларёк, как известно, деньги не печатает. Банк платит его из своей комиссии. Банк тоже деньги не печатает. Соответственно, пиво дороже того, что оно могло бы стоить на размер комиссии, помноженный на вероятность того, что покупатели расплачиваются карточками. Товарищ, кстати, тоже в проигрыше, но в чуть меньшем (на размер бонуса), чем я.
Неужели в этой примитивной бухгалтерии что-то не понятно? Что здесь доказывать? То, что ларёк деньги не печатает?
За последние 30 лет чрезвычайно развились такие прекрасные научные направления как Climate Change Studies, Gender Studies и прочие чудные научные дисциплины. Стартовав с общенаучных и гуманитарных направлений, постмодернизм добрался до физики, и сейчас её уже, говорят, дожёвывает.
По формальным критериям прогресс разогнался до невозможности, но по полезному выхлопу всё в большем количестве областей удивительным образом наблюдается отсутствие присутствия. То есть и ускорился, и замедлился одновременно. По формальным критериям ускорился, а по практической применимости замедлился. Бывает.
В принципе, ничего страшного в этой ситуации нет. Всё равно ведь, как поётся в одной известной песне, an economy based on endless growth is unsustainable.
Допустим, я покупаю пиво за нал. Мой товарищ в той же точке покупает пиво по карте. Товарищу некоторую часть потраченного возвращают бонусами. Вопрос: за чей счёт этот бонусный банкет? За счёт пивного ларька? Неа. За счёт добренького банка? Тоже нет. Выходит, я спонсирую товарищу его пиво. Единственный способ прекратить мне заниматься такой принудительной благотворительностью — самому перейти на безнал. По сути, население мягко загоняют в безнал.
Наличка — это дикая капиталистическая вольница, в которой экономические агенты взаимодействуют, не отчитываясь за каждый чих перед товарищем майором и налоговой инспекцией. Сегодня ты пиво за нал покупаешь, а завтра терроризм международный финансируешь. Не хорошо это. Надо всех загонять в безнал. Кого насильно, кого через жадность до бонусов.
По-хорошему, нужно разбираться в том, почему и как так получается, что человеческому сознанию необходимо оперировать объектами, и как в результате этого оно приходит к понятию «объект». Соответственно, нечеловеческое сознание, можно пофантазировать, свободно от наших ограничений, и может оперировать тем, что нашему пониманию недоступно, потому что объектом не является.
Человек — объект, дождь — объект, «находиться под» — отношение, которое тоже объект. Говорят, что «всё есть объекты», но это бессмыслица. Вводя любое понятие, мы обязаны (и никуда нам от этого не деться) высветить это понятие на фоне того, что под него не подпадает. Понятие «объект» не может быть исключением. Внимание, вопрос: что не является объектом?
А вот если при изготовлении фигни её автор в порыве вдохновения изобретал свой ни на что не похожий реакт — да, труба дело. Только посочувствовать.
1. Фигня — самоизобретённый велосипед. То есть не сильно заморачиваясь универсальностью сделали ровно то, что требовалось. Зависимости — только на стандартные библиотеки. Уровень перфекционизма — средненький.
2. Фигня сделана согласно полному комплекту веяний моды. Зависимости уходят в недра npm (как вариант, PyPI или чего ещё, без разницы), и там рекурсивно подхватывают существенный процент наработок сообщества.
Предположим, прошло 10 лет.
В первом случае после некоторого периода ознакомления с конструкцией пациента просто берём и докручиваем требуемое. И средство разработки, и стандартные библиотеки никуда не делись. Если нужно, на просторах Интернета можно найти что угодно, хоть 3-й турбо-паскаль.
Во втором случае оказывается, что используемые пакеты часть заброшены (и уже несовместимы со своими зависимыми), часть потерялись, часть развились так, что не узнать. Бубен в руки и вперёд, пытаемся восстановить состояние состояние инфраструктуры на тот момент, когда фигня создавалась.
В первом случае чтобы разобраться, нужно освежить знания по средству разработки и его стандартным библиотекам. Во втором — по той Джомолунгме барахла, от которого пациент зависим.
С чисто прагматической точки зрения лично я выбрал бы первое. Ну нафиг бегать с бубном вокруг Джомолунгмы.