YellowClub

Это первые издания на английском. Только через несколько лет появились переводы на русский и попытка освоения этих идей на практике.

Сложности с архитектурой не только в 1С сфере. Я общаюсь с людьми из разных команд и стеков, — вопросы те же: как разделить систему и выстроить взаимодействие ее частей. Нет такого, что все остальные давно разобрались, а одни 1С-ники отстали.

В 1С я переношу эти подходы только последние несколько лет. Поэтому понимаю и сложности, и сопротивление: мы осваиваем историю, которая еще только развивается.

А теперь к этому добавился ИИ.

Раньше мы много времени тратили на написание кода и изучение фреймворков. Теперь получаем тысячи строк за минуту. Только если одна правка по-прежнему требует изменений в пятнадцати местах, то мы просто быстрее создаем себе те же проблемы.

Мой прогноз: в ближайшие 5 лет внедрение ИИ будет дорого обходиться компаниям, в которых сотрудники разучились читать код, выстраивать архитектуру, а стали только генераторами нейрослопа.

Ребята, которые сейчас проходят этот путь, — вы стоите у истоков применения современных подходов в проектировании софта в нашем сообществе 1С. Если продолжите применять это на практике, то для вас это будет большим преимуществом. Даже без смены работы, внутри своей команде, на своей должности.

Дальше думайте сами.

мы будем учитывать в подсистеме «Учет оригиналов первичных документов» только первичные бухгалтерские документы (кстати на мой взгляд, это не тоже самое, что метаданные типа «Документ»).

И если это так, то в универсальную библиотеку БСП проник язык бухгалтерского учета. На мой взгляд это неверно, если библиотека универсальная, то в ней должен быть бизнесовый язык, отличный от языка бухгалтерии.

Т.е. в любом случае получаем проблему:

👉 если подсистема бизнесовая, то не должно иметь значения какие метаданные поставляют данные

👉 а если эта подсистема ближе к бухгалтерской (что не доказывает необходимость учета только метаданных типа «Документ»), то как она вообще оказалась в составе БСП

В такого рода рассуждениях и заключается работа Архитектора. Не в том, чтобы сказать какой регистр выбрать и нужен ли вместо регистра справочник. Это не архитектурные вопросы, это вопросы уровня реализации, уровня милда, может быть синьора.

А вот анализ языка, выстраивание границ и контроль нарушения границ — вот настоящая работа Архитектора.

Спасибо за ваш анализ архитектуры подсистемы «Учет оригиналов документов». Отдельное спасибо Александру Чугунову, Валерию Крынину, Константину, Андрею Янакаеву, Парфенову Антону за развернутые ответы.

Теперь мое мнение по поводу этой подсистемы.

1️⃣ Прежде всего, это очень интересная подсистема. В БСП таких немного. Дело в том, что большинство подсистем БСП технические, а эта бизнесовая. Она предоставляет конкретную бизнес-возможность, и относиться к ней нужно по-другому. И раз это так, то у нас возникает ряд ограничений.

Самое важное — как эта бизнес-возможность взаимодействует с другими модулями и частями системы.

Я полностью согласен с Александром Чугуновым, что взаимодействие с другими подсистемами внутри БСП для нас не так важно. Фирма 1С позиционирует БСП как что-то единое, пусть так и будет. Можно было бы разобрать зависимости от других бизнесовых подсистем БСП, но в целом бизнесовые подсистемы БСП более-менее независимы.

Поэтому посмотрим как оно связано с другими частями приложения.

2️⃣ Coupling через базу данных.

Если внимательно почитать код, то обнаружится, что подсистема «Учета оригиналов документов» обращается к базе данных и читает свойство документа: проведен он или не проведен.

Казалось бы, а что такого? Мы всегда так делаем.

Для начала попробуем разобраться, откуда вообще взялось такое бизнес-правило. Почему нас интересует именно факт проведения документа? Скорее всего и само правило неверное. Возможно, нас должен интересовать факт того, что документ распечатали или куда-то отправили. С точки зрения бизнеса это куда интереснее, чем проведен документ или нет.

Но самое интересное здесь вот что.

Проведение — это состояние самого документа, а не его отслеживаемого печатного оригинала. Оно принадлежит другой бизнес-возможности, которая отвечает за этот документ. А подсистема «Учета оригиналов» зачем-то использует это чужое состояние для принятия собственных бизнес-решений.

И это большая архитектурная проблема.

Подсистема «Учета оригиналов документов» не хранит сами документы и не владеет их свойствами. Она хранит ссылки на первичные документы, но свойства этих документов ей не принадлежат. Это не ее язык, если хотите. И когда она напрямую читает свойство «Проведен», она зависит от чужой модели данных и чужих бизнес-правил.

Допустим, завтра мы захотим учитывать оригиналы договоров, которые чаще всего являются в типовых Справочником. Получается, нам придется менять и подсистему «Учета оригиналов», хотя ее собственная бизнес-возможность никак не изменилась.

Вот это и есть coupling через базу данных. К сожалению, 1Сники в этом ничего плохого не видят и очень часто так делают и потом страдают.

Пока вот такие мысли. В следующих постах продолжу.

А вы что думаете? Coupling через базу данных — это действительно большая архитектурная проблема? Или ничего страшного, и так сойдет?