…продовження поста про заміну 1C.

Процеси

Оце цікаве місце. Очевидно, що якісь зміни повинні вміти тригернути інші зміни, або якусь інтеграцію, абощо. Можливо, тут є сенс подумати над інтерфейсом а-ля Yahoo Pipes, або Zapier/n8n/Huginn/шо там ще є на ринку. Тобто готові шматочки, які можна комбінувати. Це те, що робить Corezoid, як я розумію, а ще в мене є знайомі в Нідерландах, які будують Stekz, і я думаю, що таких речей по світу багато.

Тут одна з головних проблем — зробити процес виконання прозорим і зрозумілим, щоби дебажить було просто і зручно. А якщо зробити цю частину швидкою, то можна буде замінити сотні сторонніх сервісів, починаючи від різних сценаріїв спілкування з користувачами. :)

Модулі

Найскладніше. Я, нажаль, не дуже розуміюся на тому, як в 1С (наприклад) інтегруються різні рішення від різних контор (підозрюю що як і всюди, за допомогою програмістів і з купою нервів).

Але от я глянув поверхнево на Odoo, опенсорсний ERP, який регулярно проскакує у статтях як заміна 1C. І чомусь мені здалося, що ядро в нього мало не просто веб-фреймворк, на якому будується купа модулів, які інтегруються чисто за рахунок того, що їх пише одна компанія. Там всередині моделі (тобто, ORM, всі діла), конкретні для цього модуля, все в кращих традиціях ООП: дуже конкретно і по ділу. Не зрозумів поки що, чи є там якісь кльові додаткові абстракції, щоби модулі під конкретно Odoo взаємодіяли краще, ніж кастомно написаний софт, але здалося, що ні. І стандартне страждання в обговореннях Odoo — в нього немає української бухгалтерії, а всі існуючі модулі зав’язані на використання стандартної.

Як це обійти — дуже цікаве питання. Можливо, дуже високорівневі абстракції спасуть ситуацію: типу оцей модуль потребує колекції документів в такому форматі, і ти йому в’юшкою і джойнами організуєш і віддаєш (тобто відривання інтерфейсу роботи з данним від власне зберігання даних). Тут в мене настрій коливається від “модулі нічого не повинні знати про зберігання” версус “модулі повинні абстрагувати зберігання, а назовні виставляти інтерфейс, який потім виглядає як таблички”. Оце друге здається складнішим для імплементації, але перспективним з точки зору збереження зворотньої сумісності. І перетинається дуже з API доступа до даних, куди цікавіше було б вміти тикатися в інтерфейси, а не прямо в сирі дані — тоді є шанси апгрейдити зберігання, не ламаючи зовнішні інтеграції.

The End

Я не певен, що це всі думки, можливо ще трошки доповню, але воно задовбало в голові роїтися. Коментуйте, якщо з чимось не згодні. Або згодні. 😁

Авжеж, якщо просто зробити оце все згори — нічого не вийде, бо концепція це прекрасно, але вхід на ринок — значно більш важлива проблема. :)