У Эванса в книге язык создавался для проекта. Правда, там язык появлялся сразу, а концепция контекстов - довольно далеко. Но, я с ним согласен, потому что есть тезис: все члены проекта общаются на одном едином языке, это важно. Если проект включает несколько контекстов - значит язык их должен как-то включать все вместе. И если речь везде идет о Заказе покупателя - то там один Заказ. А если у нас есть Заказ покупателя в интернет-магазин и Заказ на доставку в транспортную компанию, то слово Заказ становится запрещенным, надо пояснять. Причина, почему язык один в том, что люди с громадным трудом переключаются между языками в ходе одной коммуникации. Путаница будет, не будут выдерживать. А то, что в разных контекстах для заказа покупателя могут быть важны важны разные атрибуты - понятно.
Вопрос о требованиях - это вопрос о границах проекта. потому что требование "Организация Х должна формировать и отправлять клиентам коммерческое предложение" можно реализовать вообще без софта, с использованием Word и электронной почты, а можно поддержать софтом в той или иной мере. Граница - очень подвижная. Основной смысл использования моделей, с моей точки зрения, в том, что они позволяют представить потенциал софта: какие решения поддержать просто, а какие - нет. А если функционал софта закрыт описанием через требования, как черный ящик, то это уже нельзя, и сплошь и рядом возникают проколы, когда бизнес требует сложные фичи, думая что это просто и наоборот, не просит удобного, не зная, что это можно несложно сделать.
Это вы не в курсе. Социократия - технология организации компаний, который работает не в малых группах, а на большом масштабе, на сотни человек точно и это проверено практикой. Это - не малые группы. И это - не мной изобретенная собственная технология, она развивается международным сообществом. И именно под таким названием - потому что в основа предложена Огюстом Контом как метод, масштабируемый на все общество. И оригинальный вариант даже пробовали в 19 веке применить в масштабах отдельно взятой страны - в Бразилии, но там не получилось. Впрочем, это - в прошлом, технология была переработана и адаптирована именно для управления компаниями, это первоначально сделали в Голландии. При этом ее можно брать не целиком, а использовать отдельные шаблоны для решения конкретных проблем. А в статье (как и в докладе), я фокусировался на тех шаблонах, которые могут быть интересны и полезны для ИТ-компаний.
Дело не в сложности/скорости управления очередью. А в том, что сообщение некоторое время в этой очереди лежит, пока не будет выбрано. И если мы оцениваем разные сценарии обработки сообщений, то надо оценивать, в том числе, скорость выбора сообщений из очереди против скорости поступления туда новых сообщений, а также задержки при обработке на ожидания от других сервисов. И размеры накапливаемых очередей. Потому что если сервис A обращается к сервису Б и ожидает ответ — то время обработки им сообщения включает время работы сервиса Б. Если он не ожидает ответа, а выбирает из очереди следующее сообщение, то скорость повышается. Но дальше там вопрос — насколько, он актуален, если после ответа Б надо еще некоторый набор действий сделать. В том числе, интересны вопросы с порядком обработки, например, если ответы пришли не в том порядке, что исходные сообщения — это может иметь какие-то эффекты. А также вопросы устойчивости при падении отдельных экземпляров сервисов — где лежат очереди, сохранятся ли они при падении, не останется ли в них сообщений, которых некому выбирать (например, если устроено так, что ответ обрабатывает именно тот тред, который посылал запрос) и так далее…
С тем же размером очереди вопрос не праздный, например, в одной из наших систем шел относительно равномерный и небольшой поток документов, в пределах 100-200 в минуту, но были выделенные моменты, когда в очередь за пару минут сваливалось 20к документов. Разбор такой очереди занимал примерно полчаса, это в принципе устраивало по бизнесу, но было две проблемы (а) основной поток желательно было разбирать с более высоким приоритетом, а не после разбора этой плюхи, (б) система управления очередью в установленной конфигурации не слишком уверенно работала с такими размерами очереди, а существенно ее усиливать ради получаса в сутки полагали недешевым удовольствием. В общем, пришлось несколько повозиться с решением. И еще мониторить внутренние очереди, потому что такой пик — он же и дальше распространялся…
На мой взгляд, асинхронное без очередей не бывает. Потому что если мы посылаем сообщение, его кто-то должен поймать, а этот кто-то может быть занят в моменте — мы можем посылать быстрее. Значит должно быть место, где необработанные сообщения накапливаются — очередь. Считать, что обработчиков всегда больше, чем потенциальных отправителей и кто-то поймает — оптимизм.
Самодостаточность — это хорошо, но сложно. Собственно, большие монолиты и вырастают из того, что в систему затягивают все больше функционала, потому что он связан с другим. Типичный пример — работа с остатками на складах или денежными. Они могут быть нужны большому количеству сервисов обработки документов при чем самых разных (разных типов заказов, сделок и так далее), и обработка документов не может быть завершена, пока он не изменит остатки (не будет зарезервирован товар для заказа или отгрузка товара, не будет переведена оплата или заблокированы деньги под сделку и так далее)…
На мой взгляд, хватает единственного ключа, который должен поставлять инициатор, это шаблон идемпотентных операций. Но дальше надо действительно аккуратно разбираться с обработкой ошибок и с тем, а зачем, собственно. нужны подтверждения и в какой момент они должны приходить. Например, почему подтверждения инициатору — когда сервис-1 обработал, а не когда обработал сервис-2 (а также 3 и 4 в более сложных случаях).
А с обработкой ошибок ситуации:
1. Что делает Сервис-1, если Сервис-2 не смог обработать (в разных вариантах)
2. Что делает Сервис-1, если он не дождался ответа от Сервис-2, при этом могло быть утеряно прямое сообщение или ответ.
3. Что делает инициатор во всех этих случаях.
Но вообще можно взять какие-нибудь схемы распределенных транзакций Oracle на техническом уровне и в них разобраться. Там же внизу — асинхронный обмен сообщениями.
Что значит «общепринятое?» Это — разные способы взаимодействия, и в статье это описано. Исторически сначала было разделение на синхронное и асинхронное, оно есть во многих учебниках, потому что синхронное — это удаленный вызов, а асинхронное — это посылка сообщения, которое когда-нибудь обработается. И если у вас канал обращения однонаправленный, как обычно при клиент-серверном взаимодействии, и при межсерверном — тоже, то никакой ответ или callback невозможен, надо опрашивать. Потом появилась возможность вызова callback при межсерверных взаимодействиях, и появился шаблон реактивного взаимодействия. При этом писали в коде это вручную, и это было тяжело. Появился реактивный манифест, на который я ссылаюсь в статье. И он — именно про реактивное взаимодействие, а не про любую асинхронную обработку сообщений. И уже потом появились промисы, и async/await, которые позволяют оборачивать асинхронное взаимодействие удобно, при этом разработчик часто не понимает, что там внутри происходит. Async/await и их аналоги в принципе могут скрывать оба способа взаимодействия, в зависимости от возможностей канала или драйвера реализации протокола, который под ними лежит.
И возвращаясь к вопросы про «общепринятое». Если это означает «вошедшее в учебники», то для IT оно — не слишком интересно, потому что учебники часто фиксируют замшелую историю. Технологии IT развиваются гораздо быстрее, чем пишут учебники. И многие новые конструкции — не осмыслены теоретиками и учебников нет. Включая мультипарадигмальные языки — в C# это есть с 2012, а теории — нет. Реактивное программирование еще моложе.
Я тут не очень понимаю, к решению какой именно задачи такой список вариантов? Задача ведения справочника контрагентов компании? Или любых справочных данных (НСИ)? Или задача интеграции новой системы в существующий ландшафт и определение принципов ведения справочника контрагентов/всех справочников. То есть разные пункты в моем представлении — разнозначимы, применимы для разных задач. И я не всегда понимаю, какой вы вкладываете смысл, например, в «Справочники/правила соответствия» — потому что вижу разные варианты.
Что касается инвеста в разработку — то есть заказная разработка для крупных компаний в области их сложных собственных процессов, которые заведомо обобщаются и не продаются. Тут фишка в том, что на большом масштабе деятельности возникает более глубокое разделение труда, специализация сотрудников, в том числе и при обработке особых случаев в процессах, которые в более мелких компаниях выполняются «на руках». У меня преимущественный опыт именно в этих проектах.
Да, примерно так и делаем. В одном из проектов было — выгрузка витрин полных документов с окном в 1.5 года — потому что была практика изменений так далеко в прошлом, и хорошо, что выгрузка с таким окном была допустима по производительности, а потом — сравнение двух ежедневных выгрузок.
И решение технических проблем, которые возникают при выгрузке витрин, а не изменений — решения для перекрестных ссылок и неконсистентности разных витрин, из-за которых, например, может придти продажа несуществующего товара, если продажи выгружают после приходов, и т.д.
Или другая интересная задача. В складскую систему передавалась накладные на отгрузку, и передающая система ожидала ответа: что из этой накладной отгружено, а что — не смогли по каким-то причинам. А складская система была устроена так, что накладная рассыпалась на строки, а строки — на множество заданий, если товар забирали с разных мест хранения, каждое исполнялось независимо, и там были сложные пути, например, чтобы взять 2 штуки из коробки, находящейся в зоне хранения целых коробов сначала исполнялось внутреннее задание по перемещению этого короба в зону хранения вскрытых коробов. Или если кладовщик фиксировал отсутствие единицы товара в конкретном месте, то формировалось задание взять ее из другого места (а эта недостача уходила на разбор). Поэтому для формирования ответа надо было вести внутренний баланс по каждой строке исходной накладной — был ли получен ответ по каждой единицы, и периодически заглядывать в складскую систему на предмет наличия неоконченных заданий…
По моему опыту, все эти вопросы решаются ситуативно. Есть некоторый парк легаси-систем, в которых исторически сложилось ведение клиентов и контрагентов, и при внедрении новой системе ставится задача — как ее вписать в сложившийся ландшафт. Ответы — различны, зависят от места системы. Иногда она объявляется мастером по ведению некоторой части справочников или даже всех, для клиентов и контрагентов так часто поступают при внедрении CRM, а не только МДМ. В других случаях она будет ведомой и получает справочники по интеграции.
Самое главное тут — прописать картину ответственности по совокупности систем. В хороших компаниях за этим следят, но в большинстве тут печалька — потому что специалисты разделены по системам, и каждый знает только про свое…
А коробку интегрируем как можем, все зависит от объема необходимого преобразований…
Я понимаю, что ответ формальный в стиле «все сложно», но реально общего решения нет.
Спасибо за отзыв, рад, что статьи вызывают такую оценку. Вопрос неравнозначности — да, важен. Но тут сталкивается политика, сила ответственных в разных системах, с вопросами компетентности персонала и техническими возможностями в принципе. Потому что если речь идет о легаси-системе, то ее возможности могут быть принципиально ограничены. Иногда — очень сильно, например, нельзя получить журнал изменений, только выгрузить витрину целиком…
Спасибо за комментарий. Потому что тема важная и сложная, и такие обсуждения дают новые грани понимания.
Да, время больших ERP точно в прошлом, да и самих ERP больше нет, все решения от одного вендора (как SAP) — просто множество модулей, просто там проблемы интеграции как-то решил вендор — и не всегда хорошо. И в практической работе мы вписываемся в тот исторически сложившийся IT-ландшафт, который есть.
Он — разный, в одних ландшафтах есть централизованное ведение справочников в одной системе, в других — есть попытка для каждого справочника определить одну мастер-систему, выделив Каталог товаров отдельно, а справочник контрагентов — отдельно, в третьих — в каждой системе свои справочники. Это As Is. И еще есть разное представление о To Be, может быть идти проект внедрения MDM (Master Data Management), часто многолетний, может идти проект внедрения CRM с решением «и всех клиентов перенесем туда, это будет главная система» и так далее. То есть везде по-разному. И в чем я точно уверен — это что это разнообразие точно будет, а вопросы развития надо решать «по месту», идеальной картины — нет, и у всех решений есть свои недостатки.
Я согласен с вами, единый MDM — не слишком хорошая идея, потому что он часто становится узким горлом в развитии. Мастер-система для каждого справочника разбивается о подробности следующего уровня, в части ведения контрагентов — клиенты и контрагенты разных типов и, особенно, договора с ними, требуют разного описания в разных системах, а один может быть во многих ролях и тут начинаются проблемы с определением мастер-системы.
Главная проблема — когда из-за ограничений в одной системе один партнер (ЮЛ) зарегистрирован несколько раз, например, потому что нет балансов расчета по разным договорам, или нельзя указать несколько валют расчета по сделкам, или предполагается, что партнер не может быть одновременно покупателем и поставщиком, а при этом в другой системе то же самое ЮЛ должно быть зарегистрировано в единственном экземпляре, иначе становятся невозможными взаимные зачеты требований-обязательств или ведение лимитов по рискам. То есть рассыпаются синонимы. Клиенты и контрагенты — самое частое, я сталкивался со случаями, когда заводили дубли в справочнике валют :) И вот я не представляю, как тут написать учебник о правильной штуке?
А с базой данных вопрос очень простой. Если там — только хранилка, логика в других местах, и именно они обеспечивают согласованность, то чтобы писать напрямую в БД надо очень хорошо знать эту логику и соблюдать ограничения целостности, иначе можно с легкостью нарушить ограничения целостности и система будет неверно работать. А API при этом — да, кривое. На чтение, обычно, проще, тут мы упираемся тупо в вопросы нагрузки.
А так же в вопросы развития системы — потому что таблицы ведь не статичны, меняются, а вечную обратную совместимость поддерживать непросто. И наиболее тяжелый вопрос — когда один объект развалили на две, например, был у контрагента расчетный счет, а теперь их может быть много, при этом другим системам по-прежнему нужен один. Вот и делают промежуточные view в надежде решить проблему.
Вообще в нынешней эпохе микросервисов и множественности баз данных, в том числе в одной системе, которые вовсе не обязательно реляционные, вопрос об организации хранения становится самостоятельным и сложным.
Я тут хочу спросить, а что именно вы предлагаете? Например, для контрагентов — легче обсуждать на конкретном примере. Единую таблицу и прямой доступ к БД? Или центральную систему, в которой собраны таблицы из всех систем и есть таблица соответствия между ними? А в чем отличия этого решения от единой системы справочников?
Примеры привести можно, я наблюдал несколько команд, в которых есть такие люди. Первая история — про внедрение продукта — там достаточно часто выясняется много деталей, о которых забыли или не учли, система работает неустойчиво, команда и пользователи — все в напряжении. И вот душа команды — он в этой ситуации успокаивает и показывает положительный прогресс. Напоминает, что фатального ничего не происходит, что процесс в целом — сходится (у меня в опыте — именно такие кейсы). И не просто сам говорит, а, например, спрашивает пользователей, которые пережили внедрения в прошлом «а если сравнить?» — и пользователей даже успокаиваются сами.
Вторая история — когда было в одном из проектов решили делать быстро и срезая углы вместо уже спроектированного полноценного решения. Для этого вроде были основания, вопрос был не очевиден, может это просто руководитель от заказчика так волюнтаристски сказал. В общем, тех, кто хотел сделать «по-хорошему» это сильно деморализовало, и душа компании в этой ситуации смог найти слова и сгладить углы, и люди приняли это решение, начали реализовывать и даже в процессе нашли компромиссный вариант, то есть часть исходного решения была встроена в то, что получилось.
В обоих случаях душа команды — не руководитель. это отдельная роль. Руководители в обоих случаях были люди, которые рационально все объяснить могли, а вот сгладить эмоции — нет. И они как руководители проекта, взаимодействующие с заказчиком были вполне уместны.
А еще в тех командах, где душа команды есть — помнят о днях рождениях, устраивают праздники и подарки, а еще — выясняют проблемы сотрудников и организуют помощь. А в других командах этого не происходит, или требует какой-то специальной организации…
Душа команды видит и сглаживает острые углы в отношениях и налаживает коммуникацию. Это не про то, что «дружить», это про эффективное взаимодействие в рабочих вопросах. Белбин выяснил, что за этой деятельностью стоит определенный набор софтскилл, который не обязательно может и должен быть у руководителя, особенно если руководитель — жесткий шейпер. И важно чтобы в команде был такой человек.
Что касается описанного кейса использования начальством, то манипуляции возможны всегда, вопрос насколько люди их принимают.
Ощущения вас обманули. Модель, как я рассказывал, основана на исследованиях, признанных научным сообществом как удовлетворяющим критериям научного исследования. Конечно, в моем изложении многое упрощено, но в целом — основано на опыте.
Педант — он нацелен на завершение задач, и если он в команде есть — то задачи завершаются, их не надо специально ему передавать, он плешь проест, что хвосты тащатся. И да, перфекционизм — его оборотная сторона, это надо контролировать. И завершает не обязательно он сам, он вполне принимает порядок, при котором завершить должен тот, кто делал. Просто его наличие снимает головную боль — думать о завершении.
Альтернативных полезных классификация много, в 2019 был обзорный доклад «Модели softskill для тимлида» mtsepkov.org/SoftSkill4IT там штук шесть или семь разных полезных моделей. А критика — она в вики есть, и в других местах можно найти, но для меня это не слишком интересно, интересна ведь не критика, а границы применения. А они следуют из характера исследований и оснований модели.
Это — непростые темы. Про языки программирования, как я писал в статье C# 2008 с linq открыл мультипарадигмальные конструкции, когда мы имеем одновременно объектную, функциональную и реляционную парадигму. И дальше практики такие композитные штуки развивают, насколько я понимаю. В Kotlin элементы этого вроде есть (хотя я глубоко не копал), JavaScript элементы таких конструкций включает… А шаблонов программирования и теоретических подходов к совмещению парадигм — не появилось. И вряд ли я тут что-то смогу написать, я не теоретик подходов к программированию.
С DDD еще интереснее, и я тоже отчасти писал. Классические объекты более-менее соответствуют структуре Enterprise-монолиты, а не микросервисы и агентов, обменивающихся сообщениями. Микросервисную и мультиагентную архитектуру надо проектировать по-другому. У меня есть мысли на этот счет, на AnalystDays буду делать об этом доклад — посмотрим, насколько получится системно изложить… Если хорошо — напишу статью.
Требования - описание системы как черного ящика, без описания конструкции. Модель - описание устройства системы, ее работы.
У Эванса в книге язык создавался для проекта. Правда, там язык появлялся сразу, а концепция контекстов - довольно далеко. Но, я с ним согласен, потому что есть тезис: все члены проекта общаются на одном едином языке, это важно. Если проект включает несколько контекстов - значит язык их должен как-то включать все вместе. И если речь везде идет о Заказе покупателя - то там один Заказ. А если у нас есть Заказ покупателя в интернет-магазин и Заказ на доставку в транспортную компанию, то слово Заказ становится запрещенным, надо пояснять. Причина, почему язык один в том, что люди с громадным трудом переключаются между языками в ходе одной коммуникации. Путаница будет, не будут выдерживать. А то, что в разных контекстах для заказа покупателя могут быть важны важны разные атрибуты - понятно.
Вопрос о требованиях - это вопрос о границах проекта. потому что требование "Организация Х должна формировать и отправлять клиентам коммерческое предложение" можно реализовать вообще без софта, с использованием Word и электронной почты, а можно поддержать софтом в той или иной мере. Граница - очень подвижная. Основной смысл использования моделей, с моей точки зрения, в том, что они позволяют представить потенциал софта: какие решения поддержать просто, а какие - нет. А если функционал софта закрыт описанием через требования, как черный ящик, то это уже нельзя, и сплошь и рядом возникают проколы, когда бизнес требует сложные фичи, думая что это просто и наоборот, не просит удобного, не зная, что это можно несложно сделать.
Это вы не в курсе. Социократия - технология организации компаний, который работает не в малых группах, а на большом масштабе, на сотни человек точно и это проверено практикой. Это - не малые группы. И это - не мной изобретенная собственная технология, она развивается международным сообществом. И именно под таким названием - потому что в основа предложена Огюстом Контом как метод, масштабируемый на все общество. И оригинальный вариант даже пробовали в 19 веке применить в масштабах отдельно взятой страны - в Бразилии, но там не получилось. Впрочем, это - в прошлом, технология была переработана и адаптирована именно для управления компаниями, это первоначально сделали в Голландии. При этом ее можно брать не целиком, а использовать отдельные шаблоны для решения конкретных проблем. А в статье (как и в докладе), я фокусировался на тех шаблонах, которые могут быть интересны и полезны для ИТ-компаний.
С тем же размером очереди вопрос не праздный, например, в одной из наших систем шел относительно равномерный и небольшой поток документов, в пределах 100-200 в минуту, но были выделенные моменты, когда в очередь за пару минут сваливалось 20к документов. Разбор такой очереди занимал примерно полчаса, это в принципе устраивало по бизнесу, но было две проблемы (а) основной поток желательно было разбирать с более высоким приоритетом, а не после разбора этой плюхи, (б) система управления очередью в установленной конфигурации не слишком уверенно работала с такими размерами очереди, а существенно ее усиливать ради получаса в сутки полагали недешевым удовольствием. В общем, пришлось несколько повозиться с решением. И еще мониторить внутренние очереди, потому что такой пик — он же и дальше распространялся…
Самодостаточность — это хорошо, но сложно. Собственно, большие монолиты и вырастают из того, что в систему затягивают все больше функционала, потому что он связан с другим. Типичный пример — работа с остатками на складах или денежными. Они могут быть нужны большому количеству сервисов обработки документов при чем самых разных (разных типов заказов, сделок и так далее), и обработка документов не может быть завершена, пока он не изменит остатки (не будет зарезервирован товар для заказа или отгрузка товара, не будет переведена оплата или заблокированы деньги под сделку и так далее)…
А с обработкой ошибок ситуации:
1. Что делает Сервис-1, если Сервис-2 не смог обработать (в разных вариантах)
2. Что делает Сервис-1, если он не дождался ответа от Сервис-2, при этом могло быть утеряно прямое сообщение или ответ.
3. Что делает инициатор во всех этих случаях.
Но вообще можно взять какие-нибудь схемы распределенных транзакций Oracle на техническом уровне и в них разобраться. Там же внизу — асинхронный обмен сообщениями.
И возвращаясь к вопросы про «общепринятое». Если это означает «вошедшее в учебники», то для IT оно — не слишком интересно, потому что учебники часто фиксируют замшелую историю. Технологии IT развиваются гораздо быстрее, чем пишут учебники. И многие новые конструкции — не осмыслены теоретиками и учебников нет. Включая мультипарадигмальные языки — в C# это есть с 2012, а теории — нет. Реактивное программирование еще моложе.
Что касается инвеста в разработку — то есть заказная разработка для крупных компаний в области их сложных собственных процессов, которые заведомо обобщаются и не продаются. Тут фишка в том, что на большом масштабе деятельности возникает более глубокое разделение труда, специализация сотрудников, в том числе и при обработке особых случаев в процессах, которые в более мелких компаниях выполняются «на руках». У меня преимущественный опыт именно в этих проектах.
И решение технических проблем, которые возникают при выгрузке витрин, а не изменений — решения для перекрестных ссылок и неконсистентности разных витрин, из-за которых, например, может придти продажа несуществующего товара, если продажи выгружают после приходов, и т.д.
Или другая интересная задача. В складскую систему передавалась накладные на отгрузку, и передающая система ожидала ответа: что из этой накладной отгружено, а что — не смогли по каким-то причинам. А складская система была устроена так, что накладная рассыпалась на строки, а строки — на множество заданий, если товар забирали с разных мест хранения, каждое исполнялось независимо, и там были сложные пути, например, чтобы взять 2 штуки из коробки, находящейся в зоне хранения целых коробов сначала исполнялось внутреннее задание по перемещению этого короба в зону хранения вскрытых коробов. Или если кладовщик фиксировал отсутствие единицы товара в конкретном месте, то формировалось задание взять ее из другого места (а эта недостача уходила на разбор). Поэтому для формирования ответа надо было вести внутренний баланс по каждой строке исходной накладной — был ли получен ответ по каждой единицы, и периодически заглядывать в складскую систему на предмет наличия неоконченных заданий…
Самое главное тут — прописать картину ответственности по совокупности систем. В хороших компаниях за этим следят, но в большинстве тут печалька — потому что специалисты разделены по системам, и каждый знает только про свое…
А коробку интегрируем как можем, все зависит от объема необходимого преобразований…
Я понимаю, что ответ формальный в стиле «все сложно», но реально общего решения нет.
Да, время больших ERP точно в прошлом, да и самих ERP больше нет, все решения от одного вендора (как SAP) — просто множество модулей, просто там проблемы интеграции как-то решил вендор — и не всегда хорошо. И в практической работе мы вписываемся в тот исторически сложившийся IT-ландшафт, который есть.
Он — разный, в одних ландшафтах есть централизованное ведение справочников в одной системе, в других — есть попытка для каждого справочника определить одну мастер-систему, выделив Каталог товаров отдельно, а справочник контрагентов — отдельно, в третьих — в каждой системе свои справочники. Это As Is. И еще есть разное представление о To Be, может быть идти проект внедрения MDM (Master Data Management), часто многолетний, может идти проект внедрения CRM с решением «и всех клиентов перенесем туда, это будет главная система» и так далее. То есть везде по-разному. И в чем я точно уверен — это что это разнообразие точно будет, а вопросы развития надо решать «по месту», идеальной картины — нет, и у всех решений есть свои недостатки.
Я согласен с вами, единый MDM — не слишком хорошая идея, потому что он часто становится узким горлом в развитии. Мастер-система для каждого справочника разбивается о подробности следующего уровня, в части ведения контрагентов — клиенты и контрагенты разных типов и, особенно, договора с ними, требуют разного описания в разных системах, а один может быть во многих ролях и тут начинаются проблемы с определением мастер-системы.
Главная проблема — когда из-за ограничений в одной системе один партнер (ЮЛ) зарегистрирован несколько раз, например, потому что нет балансов расчета по разным договорам, или нельзя указать несколько валют расчета по сделкам, или предполагается, что партнер не может быть одновременно покупателем и поставщиком, а при этом в другой системе то же самое ЮЛ должно быть зарегистрировано в единственном экземпляре, иначе становятся невозможными взаимные зачеты требований-обязательств или ведение лимитов по рискам. То есть рассыпаются синонимы. Клиенты и контрагенты — самое частое, я сталкивался со случаями, когда заводили дубли в справочнике валют :) И вот я не представляю, как тут написать учебник о правильной штуке?
А с базой данных вопрос очень простой. Если там — только хранилка, логика в других местах, и именно они обеспечивают согласованность, то чтобы писать напрямую в БД надо очень хорошо знать эту логику и соблюдать ограничения целостности, иначе можно с легкостью нарушить ограничения целостности и система будет неверно работать. А API при этом — да, кривое. На чтение, обычно, проще, тут мы упираемся тупо в вопросы нагрузки.
А так же в вопросы развития системы — потому что таблицы ведь не статичны, меняются, а вечную обратную совместимость поддерживать непросто. И наиболее тяжелый вопрос — когда один объект развалили на две, например, был у контрагента расчетный счет, а теперь их может быть много, при этом другим системам по-прежнему нужен один. Вот и делают промежуточные view в надежде решить проблему.
Вообще в нынешней эпохе микросервисов и множественности баз данных, в том числе в одной системе, которые вовсе не обязательно реляционные, вопрос об организации хранения становится самостоятельным и сложным.
Я тут хочу спросить, а что именно вы предлагаете? Например, для контрагентов — легче обсуждать на конкретном примере. Единую таблицу и прямой доступ к БД? Или центральную систему, в которой собраны таблицы из всех систем и есть таблица соответствия между ними? А в чем отличия этого решения от единой системы справочников?
Вторая история — когда было в одном из проектов решили делать быстро и срезая углы вместо уже спроектированного полноценного решения. Для этого вроде были основания, вопрос был не очевиден, может это просто руководитель от заказчика так волюнтаристски сказал. В общем, тех, кто хотел сделать «по-хорошему» это сильно деморализовало, и душа компании в этой ситуации смог найти слова и сгладить углы, и люди приняли это решение, начали реализовывать и даже в процессе нашли компромиссный вариант, то есть часть исходного решения была встроена в то, что получилось.
В обоих случаях душа команды — не руководитель. это отдельная роль. Руководители в обоих случаях были люди, которые рационально все объяснить могли, а вот сгладить эмоции — нет. И они как руководители проекта, взаимодействующие с заказчиком были вполне уместны.
А еще в тех командах, где душа команды есть — помнят о днях рождениях, устраивают праздники и подарки, а еще — выясняют проблемы сотрудников и организуют помощь. А в других командах этого не происходит, или требует какой-то специальной организации…
Что касается описанного кейса использования начальством, то манипуляции возможны всегда, вопрос насколько люди их принимают.
Педант — он нацелен на завершение задач, и если он в команде есть — то задачи завершаются, их не надо специально ему передавать, он плешь проест, что хвосты тащатся. И да, перфекционизм — его оборотная сторона, это надо контролировать. И завершает не обязательно он сам, он вполне принимает порядок, при котором завершить должен тот, кто делал. Просто его наличие снимает головную боль — думать о завершении.
И так же в других примерах.
С DDD еще интереснее, и я тоже отчасти писал. Классические объекты более-менее соответствуют структуре Enterprise-монолиты, а не микросервисы и агентов, обменивающихся сообщениями. Микросервисную и мультиагентную архитектуру надо проектировать по-другому. У меня есть мысли на этот счет, на AnalystDays буду делать об этом доклад — посмотрим, насколько получится системно изложить… Если хорошо — напишу статью.