Size: a a a

Архитектура ИТ-решений

2020 August 27

A

Andrey in Архитектура ИТ-решений
ERP на хранимках без нормального бэка
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Roman Tsirulnikov
потому что сложность системы через пару лет уже зашкаливает, ибо монолит как он есть
Можешь раскрыть?
Я видел нормально процедурно обёрнутые вызовы, которые для внешнего мира были restоподобными.
Low latency DML внутри, "я общаюсь конвенционально, вот схема" снаружи
источник

A

Andrey in Архитектура ИТ-решений
Eugene Istomin
Можешь раскрыть?
Я видел нормально процедурно обёрнутые вызовы, которые для внешнего мира были restоподобными.
Low latency DML внутри, "я общаюсь конвенционально, вот схема" снаружи
Так ты без ООП по сути.

Нет дерева обьектов бизнес логики, все - код.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Сложность в проведении границ между сегментами логики.
То самое разделение на сервисы.
Бизнес-логика оперирует множеством сущностей. Когда логика на уровне БД, все лежит в одной базе, тесно переплетенное между собой. Нет API. Нет границ/зон ответственности сервисов.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Roman Tsirulnikov
Сложность в проведении границ между сегментами логики.
То самое разделение на сервисы.
Бизнес-логика оперирует множеством сущностей. Когда логика на уровне БД, все лежит в одной базе, тесно переплетенное между собой. Нет API. Нет границ/зон ответственности сервисов.
Да, тут согласен
Я думал тебя не устроил только интерфейсный слой
источник

DM

Denis Migulin in Архитектура ИТ-решений
на схемах это разделение можно сделать и границы проводить. но вряд ли это делают
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Denis Migulin
на схемах это разделение можно сделать и границы проводить. но вряд ли это делают
ни разу не видел )
3-7 схем не считаются, так как проекты были на 100+ packages
источник

DM

Denis Migulin in Архитектура ИТ-решений
ну да, хотя инструмент есть и сделать четкое разделение по правам даже легче. Но остаются в общей базе не для этого
источник

AB

Artur BAGArt in Архитектура ИТ-решений
Саддам Хусейн
Автору в соседнем чате все косточки перемыли.
Если провести аналогию со строительством, я бы пересказал ее так.
Главный персонаж, он же и автор, много лет работал с деревом, и первоклассный спец по нему.
Обратились к нему с проблемой - построенное сикось-накось жилище расселить, для чего с нуля рядом построить новое.
Естественно, что у него нашлись и хорошие плотники среди знакомых.
Что он и сделал. И нормально, в нормы и по скорости строительства уложился и конструкция надежная - еще много жильцов вместит.
Только из дерева.
в каком из? можно в личку я б почитал )
источник

AB

Artur BAGArt in Архитектура ИТ-решений
Roman Tsirulnikov
Я когда читаю подобное “Когда мы поделились планами с разработчиками, стало понятно, что команда не готова к изменениям. Большинство людей покинули компанию: остались только те, кто пришёл совсем недавно. Чтобы провести миграцию, мы решили заново собрать команду разработки.”

всегда крайне настораживаюсь: что же они там натворили, что потребовались массовые расстрелы?
переквалифицироватся в pgsql-разрабов для рынка "такое себе"
источник

AB

Artur BAGArt in Архитектура ИТ-решений
Roman Tsirulnikov
Не вижу проблемы при условии что PL/SQL не выходит за границы работы со слоем данных, ну там например композиция, агрегация, трансформация
попробуйте там реализовать поддержку разных версий апи для мобильного
источник

AB

Artur BAGArt in Архитектура ИТ-решений
и дело даже не в том что это невозможно
источник

СХ

Саддам Хусейн... in Архитектура ИТ-решений
Artur BAGArt
в каком из? можно в личку я б почитал )
источник

JC

Jorge Cortez in Архитектура ИТ-решений
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Roman Tsirulnikov
Не вижу проблемы при условии что PL/SQL не выходит за границы работы со слоем данных, ну там например композиция, агрегация, трансформация
Там на нем JSON для фронта формируется и оркестрация сервисов делается
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Roman Tsirulnikov
Мне понравился подход C4: разделение сложности системы на уровень контекстов, на уровень взаимодействия систем, на уровень устройства отдельной системы.

Я стараюсь теперь больших схем не рисовать, а следовать подходу декомпозиции по уровням абстракций.
Получается набор простых схем. Главное качество схемы для меня сейчас это ее понятность читателям, простые схемы на нужном уровне абстракции заходят людям лучше.

Работать в PlantUML с C4, ArchiMate, UML удобно, однако он начинает непредсказуемо дурить с layout элементов если на схеме больше примерно 30 квадратиков.
А как именно работаете с исходниками?
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Кто еще работает? Как редактируете? Какие IDE юзаете?
источник

PT

Peter Tugolukov in Архитектура ИТ-решений
Как используются рендеры?
источник

IB

Igor Bespalchuk in Архитектура ИТ-решений
В CUSTIS довольно много больших старых систем было сделано на PL/SQL. Слой ООП-сущностей (поверх процедурного PL/SQL) в стиле ActiveRecord плюс слой пакетов бизнес-логики плюс слой пакетов-контроллеров, принимающих команды и отдающих XML для UI наружу. В принципе это было управляемо даже для достаточно большой кодовой базы, делилось на множество пакетов и схем для управления зависимостями. Но конечно, такой подход безбожно устарел в первую очередь морально, что тут говорить.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Peter Tugolukov
А как именно работаете с исходниками?
Git (BitBucket)
PlantUML, Jetbrains IDEA
источник