Здравствуйте, Hard_Club, Вы писали:
H_C>Разрабатывая архитектуру системы стал перед дилемой как назвать сервис, который будет отвечать на инфо-запросы из down-stream систем. Суть системы в том, что ее другие компоненты конвертят upstream-данные и складывают их в базе, откуда их и берет в готовом виде этот сервис.
Назовите его "зеленый сервис"
Нет, серьезно. Есть тема, что при разработке архитектуры не стоит (по крайней мере, заранее) давать компонентам сколь-нибудь осмысленные имена. Т.к. это сразу начинает на уровне подсознания влиять на принятие решения о том, что этот конкретный квадратик должен делать.
Здравствуйте, scale_tone, Вы писали:
_>Нет, серьезно. Есть тема, что при разработке архитектуры не стоит (по крайней мере, заранее) давать компонентам сколь-нибудь осмысленные имена. Т.к. это сразу начинает на уровне подсознания влиять на принятие решения о том, что этот конкретный квадратик должен делать.
А я считаю, что архитектору надо выделить из общей функциональности "некий конкретный квадратик" по назначению. Потом исходя из этого нужно решить, как он будет называться.
Иначе получится так же как с астрологическим прогнозом, сначала пишется гороскоп, потом расставляются знаки зодиака.
Разрабатывая архитектуру системы стал перед дилемой как назвать сервис, который будет отвечать на инфо-запросы из down-stream систем. Суть системы в том, что ее другие компоненты конвертят upstream-данные и складывают их в базе, откуда их и берет в готовом виде этот сервис.
Здравствуйте, Hard_Club, Вы писали:
H_C>Разрабатывая архитектуру системы стал перед дилемой как назвать сервис, который будет отвечать на инфо-запросы из down-stream систем. Суть системы в том, что ее другие компоненты конвертят upstream-данные и складывают их в базе, откуда их и берет в готовом виде этот сервис.
info service
H_C>Разрабатывая архитектуру системы стал перед дилемой как назвать сервис, который будет отвечать на инфо-запросы из down-stream систем. Суть системы в том, что ее другие компоненты конвертят upstream-данные и складывают их в базе, откуда их и берет в готовом виде этот сервис.
Здравствуйте, velkin, Вы писали:
V>А я считаю, что архитектору надо выделить из общей функциональности "некий конкретный квадратик" по назначению. Потом исходя из этого нужно решить, как он будет называться.
Все верно, только выделить нужно не один квадратик, а несколько. И что более важно — правильно определить границы между квадратиками. Так вот как раз определять границы лучше до наклеивания стикеров (ярлыков) на квадратики. Чтобы эти ярлыки ничего тебе не навязывали. А еще границы между квадратиками часто нужно двигать в процессе жизненного цикла системы. И тут опять же названия зашоривают — мешают увидеть более правильное решение.
Тема идет из идеологии SOA, но на самом деле вполне применима и к "микро-миру": классам там, интерфейсам и т.д.