Все верно, аналог, построенный вокруг <операционных показателей>, а не бухгалтерии, адаптированный под мсб. В статье акцентирую внимание на том, что не стремлюсь повторить функционал 1с или стать его копией. Думаю очевидно, что это просто невозможно, да и бессмысленно.
Вполне возможно, что и так, на 100% мало кто что-то понимает. Возьмусь утверждать лишь только то, что все модули строились исходя из принципов, которые я наблюдал всё это время в сервисе и парочке смежных организаций такого же масштаба.
Да, сделать абсолютно для всех не получится, но определённый функционал (те же финансы, но интегрированные напрямую в управление сделками) отлично ложится на большинство известных мне предприятий.
Повторюсь: особенностью и в целом главным преимуществом Kroncl не является какой-то конкретный модуль или функции обмена с 1С. При разработке просто-напросто не ставилось задачи быть с ним совместимым. Такое отношение может показаться поверхностным (ведь каждая вторая организация ведёт бухгалтерию в 1С -> нужно обеспечивать совместимость) — но здесь дело больше в общей сути и целевой платформы.
Основная идея и задача (не озвучена в статье, но сквозит в каждом слове про изоляцию данных организаций) — это возможность быстро развёртывать своего рода инстансы малого бизнеса прямо в облачке, минуя интеграторов, демо-стенды и прочий сюр. Каждый такой инстанс имеет свои настройки тарификации, свои настройки прав, свой состав модулей и так далее. И у предпринимателей/финансистов/аутсорс-агентств появляется возможность вести хоть 10, хоть 100, хоть 1000 таких организаций-заказчиков параллельно, переключаясь между пространствами за секунды.
По поводу самой предметной области ERP повторю тезис из статьи: Kroncl не рассчитан на бухгалтерию. Любому специалисту 1С всё это покажется абсурдом, но дело в том, что 1С сделан для специалистов по 1С, а Kroncl — для обычных предпринимателей. В масштабах организаций до условных 10-15 человек (а таких десятки тысяч, часть из которых и не пытается вести бухгалтерию) необходимый функционал покрывается 5-6 модулями: финансы, сделки, клиенты, склад, сотрудники. Совместив автоматизацию процесса создания инстансов с относительной простотой и функциональностью модулей, без сомнений можно добиться определённых результатов.
То, что есть на рынке сейчас для этого сегмента предпринимателей - либо срмки (под капотом которых единая свалка данных), либо только фин.учёт, либо только склад (МойСклад), либо наш любимый 1с или попытки его повторить. Никто не собирался делать удобно, дёшево и функционально для предприятий такого микро-масштаба (смысла в этом с точки зрения выгоды мало), я собрался - я делаю (собственно про это и статья).
Соглашусь, в большинстве проектов такого рода партнёрская сеть является не опцией, а основным требованием для хоть какого-либо развития. По поводу работы - в большинстве компаний, решающих аналогичные задачи, весь проект сводится к "коробочной" ERP, пусть даже и на современном стеке.
По правде сказать, интересно мне было сделать не столько саму ERP (хотя и не без этого), сколько грамотную изоляцию, и в целом воссоздать концепцию "покупки ресурсов" инстанса для управления бизнесом. Основная идея здесь - не столько повторить 1с или что-то в этом духе, сколько дать возможность вести параллельно хоть 10 организаций, каждая из которых бы имела свои настройки тарификации, свои лимиты хранилища, свой состав модулей.
Автоматизировать процесс создания таких организаций и организовать работоспособность всех инстансов в облаке - вот это наверное самая интересная часть.
Утверждаю ли я, что 1с нужно чем-то заменять? - нет, не утверждаю (как и в любой системе есть минусы и плюсы, просто в случае конкретно 1с плюсы перевешивают минусы [с точки зрения рынка])
Обязаны ли все системы управления предприятиями выглядеть как 1с? - нет, не обязаны (разные масштабы -> разные цели -> разные способы реализации)
По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:
Отладка этого добра.
Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.
А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?
Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.
Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.
Понимание кода.
Возможно для команды из 1 человека проще скинуть все на контекст, оставив себе лишь написание самой логики, но на деле поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята.
Тестирование.
Здесь говорить даже ничего не надо. Думаю всем понятно, что глобальные состояния без обоснованных на то причин (это не обоснованная) если и не запрещены, то являются признаком дурного тона....именно по причине сложности тестирования.
Очереди+консольные команды.
Это вообще пиздец, я думаю и так понятно, что все эти глобальные скоупы отметаются.
Запросы к общим схемам.
Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.
Что касается ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.
Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.
Все верно, аналог, построенный вокруг <операционных показателей>, а не бухгалтерии, адаптированный под мсб. В статье акцентирую внимание на том, что не стремлюсь повторить функционал 1с или стать его копией. Думаю очевидно, что это просто невозможно, да и бессмысленно.
Вполне возможно, что и так, на 100% мало кто что-то понимает. Возьмусь утверждать лишь только то, что все модули строились исходя из принципов, которые я наблюдал всё это время в сервисе и парочке смежных организаций такого же масштаба.
Да, сделать абсолютно для всех не получится, но определённый функционал (те же финансы, но интегрированные напрямую в управление сделками) отлично ложится на большинство известных мне предприятий.
Благодарю за комментарий и замечание по партнёрам. Наверное, из-за таких оценок до сих пор и пишу.
Повторюсь: особенностью и в целом главным преимуществом Kroncl не является какой-то конкретный модуль или функции обмена с 1С. При разработке просто-напросто не ставилось задачи быть с ним совместимым. Такое отношение может показаться поверхностным (ведь каждая вторая организация ведёт бухгалтерию в 1С -> нужно обеспечивать совместимость) — но здесь дело больше в общей сути и целевой платформы.
Основная идея и задача (не озвучена в статье, но сквозит в каждом слове про изоляцию данных организаций) — это возможность быстро развёртывать своего рода инстансы малого бизнеса прямо в облачке, минуя интеграторов, демо-стенды и прочий сюр. Каждый такой инстанс имеет свои настройки тарификации, свои настройки прав, свой состав модулей и так далее. И у предпринимателей/финансистов/аутсорс-агентств появляется возможность вести хоть 10, хоть 100, хоть 1000 таких организаций-заказчиков параллельно, переключаясь между пространствами за секунды.
По поводу самой предметной области ERP повторю тезис из статьи: Kroncl не рассчитан на бухгалтерию. Любому специалисту 1С всё это покажется абсурдом, но дело в том, что 1С сделан для специалистов по 1С, а Kroncl — для обычных предпринимателей. В масштабах организаций до условных 10-15 человек (а таких десятки тысяч, часть из которых и не пытается вести бухгалтерию) необходимый функционал покрывается 5-6 модулями: финансы, сделки, клиенты, склад, сотрудники. Совместив автоматизацию процесса создания инстансов с относительной простотой и функциональностью модулей, без сомнений можно добиться определённых результатов.
То, что есть на рынке сейчас для этого сегмента предпринимателей - либо срмки (под капотом которых единая свалка данных), либо только фин.учёт, либо только склад (МойСклад), либо наш любимый 1с или попытки его повторить. Никто не собирался делать удобно, дёшево и функционально для предприятий такого микро-масштаба (смысла в этом с точки зрения выгоды мало), я собрался - я делаю (собственно про это и статья).
Соглашусь, в большинстве проектов такого рода партнёрская сеть является не опцией, а основным требованием для хоть какого-либо развития. По поводу работы - в большинстве компаний, решающих аналогичные задачи, весь проект сводится к "коробочной" ERP, пусть даже и на современном стеке.
По правде сказать, интересно мне было сделать не столько саму ERP (хотя и не без этого), сколько грамотную изоляцию, и в целом воссоздать концепцию "покупки ресурсов" инстанса для управления бизнесом. Основная идея здесь - не столько повторить 1с или что-то в этом духе, сколько дать возможность вести параллельно хоть 10 организаций, каждая из которых бы имела свои настройки тарификации, свои лимиты хранилища, свой состав модулей.
Автоматизировать процесс создания таких организаций и организовать работоспособность всех инстансов в облаке - вот это наверное самая интересная часть.
Утверждаю ли я, что 1с нужно чем-то заменять? - нет, не утверждаю (как и в любой системе есть минусы и плюсы, просто в случае конкретно 1с плюсы перевешивают минусы [с точки зрения рынка])
Обязаны ли все системы управления предприятиями выглядеть как 1с? - нет, не обязаны (разные масштабы -> разные цели -> разные способы реализации)
И не поспоришь ведь даже...в контексте "детерминированного контекста"
По моему скромному мнению мультитенантность на пхп (да и не только) напротив сильно недооценена. И на то есть несколько основных причин:
Отладка этого добра.
Вы предлагаете делегировать установку глобального контекста на мидлварь для роутов, связанных с клиентской логикой. И казалось бы всё отлично, хэндлеры пишем как-будто бы для одного клиента.
А что будет, если по каким-то неведомым или случайным причинам последовательность установки контекста будет нарушена или упоси господи произойдёт установка неправильного?
Произойдет пиздец, выявление почему и где это случилось займет немало времени, а устранение последствий ещё больше.
Красота ручного конфигурирования pdo соединения для конкретного тенанта через связку роутера + фабрики репозиториев как раз в том, что все строго изолировано. Нет никакого магического глобального состояния, шанс накосячить мал или вообще сводится к нулю. Мы просто принимаем uuid тенанта из мидлваря (например из jwt), и говорим, мне нужны репозитории под тенанта вот с таким ключом. И да, делаем так каждый раз, когда нам требуется взаимодействие с базой данных. В обмен на две строки в каждом хэндлере получаем изоляцию каждого роута и как следствие безопасность.
Понимание кода.
Возможно для команды из 1 человека проще скинуть все на контекст, оставив себе лишь написание самой логики, но на деле поддержка такого кода опять же по моему скромному мнению усложняется. Магия, ребята.
Тестирование.
Здесь говорить даже ничего не надо. Думаю всем понятно, что глобальные состояния без обоснованных на то причин (это не обоснованная) если и не запрещены, то являются признаком дурного тона....именно по причине сложности тестирования.
Очереди+консольные команды.
Это вообще пиздец, я думаю и так понятно, что все эти глобальные скоупы отметаются.
Запросы к общим схемам.
Условно в схеме shared у вас хранятся iso коды валют. И что очевидно при написании логики отдельного тенанта они могут потребоваться. Манипуляции по переключению с глобального контекста займут время.
Что касается
ResultType. Идея просто в том, чтобы сделать ошибки частью возвращаемого каждым звеном приложения ответа. Это шаг в сторону той самой строгости и контрактности, которые опять же по моему скромному мнению необходимы в крупных multitenancy проектах.Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Вариант конечно живой, но есть и альтернатива.
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.