A
ERP на хранимках без нормального бэка
Size: a a a
2020 August 27
EI
потому что сложность системы через пару лет уже зашкаливает, ибо монолит как он есть
Можешь раскрыть?
Я видел нормально процедурно обёрнутые вызовы, которые для внешнего мира были restоподобными.
Low latency DML внутри, "я общаюсь конвенционально, вот схема" снаружи
Я видел нормально процедурно обёрнутые вызовы, которые для внешнего мира были restоподобными.
Low latency DML внутри, "я общаюсь конвенционально, вот схема" снаружи
A
Можешь раскрыть?
Я видел нормально процедурно обёрнутые вызовы, которые для внешнего мира были restоподобными.
Low latency DML внутри, "я общаюсь конвенционально, вот схема" снаружи
Я видел нормально процедурно обёрнутые вызовы, которые для внешнего мира были restоподобными.
Low latency DML внутри, "я общаюсь конвенционально, вот схема" снаружи
Так ты без ООП по сути.
Нет дерева обьектов бизнес логики, все - код.
Нет дерева обьектов бизнес логики, все - код.
RT
Сложность в проведении границ между сегментами логики.
То самое разделение на сервисы.
Бизнес-логика оперирует множеством сущностей. Когда логика на уровне БД, все лежит в одной базе, тесно переплетенное между собой. Нет API. Нет границ/зон ответственности сервисов.
То самое разделение на сервисы.
Бизнес-логика оперирует множеством сущностей. Когда логика на уровне БД, все лежит в одной базе, тесно переплетенное между собой. Нет API. Нет границ/зон ответственности сервисов.
EI
Сложность в проведении границ между сегментами логики.
То самое разделение на сервисы.
Бизнес-логика оперирует множеством сущностей. Когда логика на уровне БД, все лежит в одной базе, тесно переплетенное между собой. Нет API. Нет границ/зон ответственности сервисов.
То самое разделение на сервисы.
Бизнес-логика оперирует множеством сущностей. Когда логика на уровне БД, все лежит в одной базе, тесно переплетенное между собой. Нет API. Нет границ/зон ответственности сервисов.
Да, тут согласен
Я думал тебя не устроил только интерфейсный слой
Я думал тебя не устроил только интерфейсный слой
DM
на схемах это разделение можно сделать и границы проводить. но вряд ли это делают
EI
Denis Migulin
на схемах это разделение можно сделать и границы проводить. но вряд ли это делают
ни разу не видел )
3-7 схем не считаются, так как проекты были на 100+ packages
3-7 схем не считаются, так как проекты были на 100+ packages
DM
ну да, хотя инструмент есть и сделать четкое разделение по правам даже легче. Но остаются в общей базе не для этого
AB
Автору в соседнем чате все косточки перемыли.
Если провести аналогию со строительством, я бы пересказал ее так.
Главный персонаж, он же и автор, много лет работал с деревом, и первоклассный спец по нему.
Обратились к нему с проблемой - построенное сикось-накось жилище расселить, для чего с нуля рядом построить новое.
Естественно, что у него нашлись и хорошие плотники среди знакомых.
Что он и сделал. И нормально, в нормы и по скорости строительства уложился и конструкция надежная - еще много жильцов вместит.
Только из дерева.
Если провести аналогию со строительством, я бы пересказал ее так.
Главный персонаж, он же и автор, много лет работал с деревом, и первоклассный спец по нему.
Обратились к нему с проблемой - построенное сикось-накось жилище расселить, для чего с нуля рядом построить новое.
Естественно, что у него нашлись и хорошие плотники среди знакомых.
Что он и сделал. И нормально, в нормы и по скорости строительства уложился и конструкция надежная - еще много жильцов вместит.
Только из дерева.
в каком из? можно в личку я б почитал )
AB
Я когда читаю подобное “Когда мы поделились планами с разработчиками, стало понятно, что команда не готова к изменениям. Большинство людей покинули компанию: остались только те, кто пришёл совсем недавно. Чтобы провести миграцию, мы решили заново собрать команду разработки.”
всегда крайне настораживаюсь: что же они там натворили, что потребовались массовые расстрелы?
всегда крайне настораживаюсь: что же они там натворили, что потребовались массовые расстрелы?
переквалифицироватся в pgsql-разрабов для рынка "такое себе"
AB
Не вижу проблемы при условии что PL/SQL не выходит за границы работы со слоем данных, ну там например композиция, агрегация, трансформация
попробуйте там реализовать поддержку разных версий апи для мобильного
AB
и дело даже не в том что это невозможно
JC
PD
Не вижу проблемы при условии что PL/SQL не выходит за границы работы со слоем данных, ну там например композиция, агрегация, трансформация
Там на нем JSON для фронта формируется и оркестрация сервисов делается
PT
Мне понравился подход C4: разделение сложности системы на уровень контекстов, на уровень взаимодействия систем, на уровень устройства отдельной системы.
Я стараюсь теперь больших схем не рисовать, а следовать подходу декомпозиции по уровням абстракций.
Получается набор простых схем. Главное качество схемы для меня сейчас это ее понятность читателям, простые схемы на нужном уровне абстракции заходят людям лучше.
Работать в PlantUML с C4, ArchiMate, UML удобно, однако он начинает непредсказуемо дурить с layout элементов если на схеме больше примерно 30 квадратиков.
Я стараюсь теперь больших схем не рисовать, а следовать подходу декомпозиции по уровням абстракций.
Получается набор простых схем. Главное качество схемы для меня сейчас это ее понятность читателям, простые схемы на нужном уровне абстракции заходят людям лучше.
Работать в PlantUML с C4, ArchiMate, UML удобно, однако он начинает непредсказуемо дурить с layout элементов если на схеме больше примерно 30 квадратиков.
А как именно работаете с исходниками?
PT
Кто еще работает? Как редактируете? Какие IDE юзаете?
PT
Как используются рендеры?
IB
В CUSTIS довольно много больших старых систем было сделано на PL/SQL. Слой ООП-сущностей (поверх процедурного PL/SQL) в стиле ActiveRecord плюс слой пакетов бизнес-логики плюс слой пакетов-контроллеров, принимающих команды и отдающих XML для UI наружу. В принципе это было управляемо даже для достаточно большой кодовой базы, делилось на множество пакетов и схем для управления зависимостями. Но конечно, такой подход безбожно устарел в первую очередь морально, что тут говорить.
RT
А как именно работаете с исходниками?
Git (BitBucket)
PlantUML, Jetbrains IDEA
PlantUML, Jetbrains IDEA