S
некоторые банки пытаются тоже в духе DoDAF использовать
Size: a a a
2020 June 06
S
не наши
LV
И не получалось создать сквозные модели от идеи до развертывания?
Смотря на каком уровне. У меня модель описывает от high level design и до конкретных сервисов (микросервисов, если угодно). В код уже не вмешиваюсь.
Есть маппинг между функциональными требованиями и сервисами, плюс прохождение основных сценариев.
Есть маппинг между функциональными требованиями и сервисами, плюс прохождение основных сценариев.
LV
И это именно модель в visual paradigm
LV
https://cdn2.hubspot.net/hubfs/2570476/Blog/Reference-Architecture-and-Framework.pdf - может пригодиться кому-то
S
если модель не доходит до кода, она - иллюстрация
S
но бывает полезна
S
если конкретные сервисы. то хотя бы GraphQL/gRPC схемы можно сгенерить для API
LV
И потом замучится все это дело синхронизировать под конкретные кейсы? Нет, спасибо )
LV
я бы сказал даже "мини кейсы" из серии "а вот решили еще отчество выводить, давайте и это поле прокинем на ui"
PD
если модель не доходит до кода, она - иллюстрация
А в чем смысл подобных моделей? Вот с генерацией API и даже кода?
PD
(видел попытку делать проект по модели, но лет 15 назад. Кончилось срывом всех сроков и бюджетов. Правда, там и идеологи были некомпетентны и заказ был на кусочек ГАС Выборы)
NK
В ограниченном контексте Концептуальная -> Логическая -> Физическа модели -> База Данных -> DAO почему и нет - все генериться )и везде одинаковые наименования. Концептуальня модель понятна бизнесу, остальное для разработачиков
EI
А в чем смысл подобных моделей? Вот с генерацией API и даже кода?
Думаю, под "моделью" мы часто понимаем "квадратики в UI".
Но суть в том, что идти нужно с двух сторон одновременно: из кода в метаданные + из метаданных в код.
Но суть в том, что идти нужно с двух сторон одновременно: из кода в метаданные + из метаданных в код.
NK
Думаю, под "моделью" мы часто понимаем "квадратики в UI".
Но суть в том, что идти нужно с двух сторон одновременно: из кода в метаданные + из метаданных в код.
Но суть в том, что идти нужно с двух сторон одновременно: из кода в метаданные + из метаданных в код.
ИМХО направление должно быть одно, иначе с какой-то из сторон или огромный оверхэд по трудозатратам или утсраевание и как итог бесполезность
PD
В ограниченном контексте Концептуальная -> Логическая -> Физическа модели -> База Данных -> DAO почему и нет - все генериться )и везде одинаковые наименования. Концептуальня модель понятна бизнесу, остальное для разработачиков
Ну, это не модель, это декларация структуры данных, тут нет привязки к сценариям, сущностей СУБД кроме таблиц, возможности проверить активные действия (запросы, модификации), определить какие-то параметры структуры данных (даже целостность).
Т.е. мы не получим никаких плюсов, но будет куча минусов (обычно построенные таким образом БД крайне неэффективны).
Т.е. мы не получим никаких плюсов, но будет куча минусов (обычно построенные таким образом БД крайне неэффективны).
PD
Думаю, под "моделью" мы часто понимаем "квадратики в UI".
Но суть в том, что идти нужно с двух сторон одновременно: из кода в метаданные + из метаданных в код.
Но суть в том, что идти нужно с двух сторон одновременно: из кода в метаданные + из метаданных в код.
Вот про "из метаданных в код" - можешь какой-то осмысленый пример привести?
PD
ИМХО направление должно быть одно, иначе с какой-то из сторон или огромный оверхэд по трудозатратам или утсраевание и как итог бесполезность
Ну да, лучше от кода (или работающей системы) в модель.
EI
Вот про "из метаданных в код" - можешь какой-то осмысленый пример привести?
Да, немного позже
LV
В ограниченном контексте Концептуальная -> Логическая -> Физическа модели -> База Данных -> DAO почему и нет - все генериться )и везде одинаковые наименования. Концептуальня модель понятна бизнесу, остальное для разработачиков
Ну это модель не архитектуры, а модель предметной области. Разные вещи.