Некоторые предметные области повторяются в разных проектах. Интересно существует ли какая-нибудь книга или сайт где можно найти типовые решения (reference architectures) для часто встречаемых проектов,
например,
— Онлайн банк
— Система бронирования... (билетов или чего-нибудь)
— Медицинская клиника
— Онлайн чат
итд, итп
Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри
MZ>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри
Вот конкретно не видал.
Но есть Шаблоны корпоративных приложений.
А зачем тебе тогда плагин для Zoom?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
MZ>>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри LVV>Вот конкретно не видал. LVV>Но есть Шаблоны корпоративных приложений. LVV>А зачем тебе тогда плагин для Zoom?
Здравствуйте, MikhailZ, Вы писали:
MZ>Здравствуйте, LaptevVV, Вы писали:
MZ>>>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри LVV>>Вот конкретно не видал. LVV>>Но есть Шаблоны корпоративных приложений. LVV>>А зачем тебе тогда плагин для Zoom?
MZ>Сорри. Это как-то осталось от предыдущего поста
Шаблоны корпоративных приложений — я читал эту книгу. Я ищу что-то более высокоуровневое, для набора предметных областей, шаблоны же низкоуровневые, и это не архитектура
Здравствуйте, MikhailZ, Вы писали:
MZ>Некоторые предметные области повторяются в разных проектах. Интересно существует ли какая-нибудь книга или сайт где можно найти типовые решения (reference architectures) для часто встречаемых проектов, MZ>например, MZ>- Онлайн банк MZ>- Система бронирования... (билетов или чего-нибудь) MZ>- Медицинская клиника MZ>- Онлайн чат MZ> итд, итп MZ>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри
Здравствуйте, MikhailZ, Вы писали:
MZ>Некоторые предметные области повторяются в разных проектах. Интересно существует ли какая-нибудь книга или сайт где можно найти типовые решения (reference architectures) для часто встречаемых проектов, MZ>например, MZ>- Онлайн банк MZ>- Система бронирования... (билетов или чего-нибудь) MZ>- Медицинская клиника MZ>- Онлайн чат MZ> итд, итп MZ>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри
Здравствуйте, MikhailZ, Вы писали:
MZ>Некоторые предметные области повторяются в разных проектах. Интересно существует ли какая-нибудь книга или сайт где можно найти типовые решения (reference architectures) для часто встречаемых проектов, MZ>например, MZ>- Онлайн банк MZ>- Система бронирования... (билетов или чего-нибудь) MZ>- Медицинская клиника MZ>- Онлайн чат MZ> итд, итп MZ>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри
Это не архитектурный подход, это интеграция (хакинг). Ты находишь готовые рабочие куски и собираешь из них то, что решает твою задачу. Если у тебя запуск проекта начинается с копирования любимых кусков кода из запасников, ты уже встал на путь интеграции.
Архитектура это про сбор требований и их анализ. Набор требований уникален, иначе зачем бы тебя попросили делать новую систему вместо покупки или доводки готовой.
Здравствуйте, Vladek, Вы писали:
V>Здравствуйте, MikhailZ, Вы писали:
MZ>>Некоторые предметные области повторяются в разных проектах. Интересно существует ли какая-нибудь книга или сайт где можно найти типовые решения (reference architectures) для часто встречаемых проектов, MZ>>например, MZ>>- Онлайн банк MZ>>- Система бронирования... (билетов или чего-нибудь) MZ>>- Медицинская клиника MZ>>- Онлайн чат MZ>> итд, итп MZ>>Для каждой такой системы должна быть модель БД, модель показывающая компоненты, вызываемый сервисы, как это устроено внутри
V>Это не архитектурный подход, это интеграция (хакинг). Ты находишь готовые рабочие куски и собираешь из них то, что решает твою задачу. Если у тебя запуск проекта начинается с копирования любимых кусков кода из запасников, ты уже встал на путь интеграции.
V>Архитектура это про сбор требований и их анализ. Набор требований уникален, иначе зачем бы тебя попросили делать новую систему вместо покупки или доводки готовой.
Архитектура или Дизайн. Эти понятия иногда используются взаимозаменяемо. Если посмотресть на ю-тюбе очень часто это называют System design
Идея в том чтобы иметь набор типовых архитектур чтобы не начинать с нуля
Всегда полезно посмотреть на примеры когда ты что-то проектируешь
