Здравствуйте, BlackEric, Вы писали:
BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?
А какое отношение к архитектуре имеют мобильные приложения и выбор протокола сериализации приложения?
Это все совершенно несущественные частности...
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>А какое отношение к архитектуре имеют мобильные приложения и выбор протокола сериализации приложения? ДФ>Это все совершенно несущественные частности...
С чего ты вдруг решил, что для его приложения это несущественные частности?
ДФ>А какое отношение к архитектуре имеют мобильные приложения и выбор протокола сериализации приложения?
Протокол сериализации, да, частность, хотя такая, что потом будет влиять на все.
А обпеспечение взаимодействия с мобильным приложение — однозначно должно закладываться в архитектуре. Для него необходимо выставлять АПИ. Для обеспечения единоообразия это же апи по хорошему должен использовать и веб интерфейс.
Здравствуйте, BlackEric, Вы писали:
BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?
Думаю что для начала нужно определиться с тем, что же такое архитектура, а уже потом говорить о книгах. Архитектура, это не про мобильное приложение и не про десктопное и не про xml vs json. Арихтектура даже не про бэкенд или фронтенд. Архитектура это про программно-аппаратный комплекс, который решает бизнес задачи. Именно комплекс, который нацелен на решения задач бизнеса/пользователя.
В то же время дизайн — это как раз про xml vs json, мобильные приложения, бэкенд, фронтенд, реляционные базы VS k/v хранилища. Само собой, пересечение между архитектурой и дизайном есть и оно огромное, но акценты в обоих случаях сильно разные.
Здравствуйте, BlackEric, Вы писали:
BE>Вот только в названии в обоих случаях Architecture. Надо подумать где разница между дизайном и архитектурой.
Насколько я помню Architecture in Practice, там как раз есть размышления на тему отличия архитектуры от дизайна с которыми я полностью согласен и привел выше. Да и если посмотреть на вакансии архитекторов то видно, что архитектура, обычно — это про весь комплекс в целом, как минимум на уровне подразделения компании.
Здравствуйте, BlackEric, Вы писали:
BE>Протокол сериализации, да, частность, хотя такая, что потом будет влиять на все.
BE>А обпеспечение взаимодействия с мобильным приложение — однозначно должно закладываться в архитектуре. Для него необходимо выставлять АПИ. Для обеспечения единоообразия это же апи по хорошему должен использовать и веб интерфейс.
Здравствуйте, BlackEric, Вы писали:
BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?
Мне кажется что если выбор xml vs json на что-то влияет, то архитектура плохая.
А вот про мобильные клиенты и оффлайн действительно у фаулера ничего нет, тогда все было по-другому.
Что читать — About face Алана Купера (Проектирование интерфейсов), там для архитектора приложений полезных сведений гораздо больше, чем в любой книге по арихеткруте и дизайну.
Здравствуйте, BlackEric, Вы писали:
BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?
Из собственного опыта — читаем что написано у Фаулера и делаем 100% наоборот.
Здравствуйте, kaa.python, Вы писали:
C>>Из собственного опыта — читаем что написано у Фаулера и делаем 100% наоборот. KP>Этой книги Фаулера я вроде не читал, но мнение очень интересное. Не затруднит 1-2 примера привести? Очень заинтриговал
Например, пропаганда DTO-объектов, богатой доменной модели и мусора типа "стратегий". Совершенно не упомянуто об асинхронной модели, для долгоиграющих операций. Мелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был.
Что нельзя простить — совершенно бездарное описание работы удалённых сервисов, оно там в худшем стиле начала 90-х. Почти ни один из его примеров не пройдёт review у меня: нет обработки сетевых ошибок и retry, нет стратегии обеспечения идемпотентности, нет анализа на поведение при ошибках downstream-сервисов и т.д.
Нет упоминаний о трассировке и метриках для профилирования. Нет упоминаний о мониторинге и тревожных сигналах. Нет упоминаний о стратегии обеспечения безопасности межсервисных вызовов или о механизмах передачи identity вызывающего.
В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?
Здравствуйте, Cyberax, Вы писали:
C>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?
На книгу редко у кого времени хватает. Хотя бы начать с серии статей — было бы здорово.
Best regards, Буравчик
Re[4]: отделять "веб север" от "сервера приложений"
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>НМелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был.
S>А что тут не так? Почему отделять плохо?
Наверное, про то, что сейчас API в серверах приложений строится практически всегда с использованием HTTP. Т.е. серверы приложений являются веб-серверами.
C>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?
А напиши, серьёзно. Вангую, заработаешь ещё 1кк$
Sic luceat lux!
Re[5]: отделять "веб север" от "сервера приложений"
Здравствуйте, Sharov, Вы писали:
C>>НМелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был. S>А что тут не так? Почему отделять плохо?
В 2006-м году веб-сервер был отдельной фигнёй, которая выдавала динамический HTML в ответ на запросы пользователей.
Сейчас корпоративные приложения на 90% построены в виде статических JS/HTML/CSS модулей, которые загружаются с какого-либо CDN. Затем этот JS уже просто напрямую вызывает backend'овые сервисы. Т.е. классический динамический веб-сервер как таковой часто вообще отсутствует.
Здравствуйте, Cyberax, Вы писали:
C>Что нельзя простить — совершенно бездарное описание работы удалённых сервисов, оно там в худшем стиле начала 90-х. Почти ни один из его примеров не пройдёт review у меня: нет обработки сетевых ошибок и retry, нет стратегии обеспечения идемпотентности, нет анализа на поведение при ошибках downstream-сервисов и т.д.
C>Нет упоминаний о трассировке и метриках для профилирования. Нет упоминаний о мониторинге и тревожных сигналах. Нет упоминаний о стратегии обеспечения безопасности межсервисных вызовов или о механизмах передачи identity вызывающего.
"пропаганда DTO-объектов и богатой доменной модели" есть везде, в том числе в whitepapers от Майкрософт т.к. без них написать современную систему невозможно. Я уже давно читал его книжки, но асинхронные методы, сетевые ошибки и прочее там вполне были. Даже про identity базовые на тот момент вещи (куки по-сути) там вроде упоминались, конечно про токены ничего не было, т.к. и самих токенов тогда еще не изобрели. Вообще сейчас сильный уклон в микросервисы, облака и SPA, которых тогда тоже не было, и про них уже достаточно много хорошей литературы. Сами по себе паттерны от Фаулера вполне актуальны
Здравствуйте, Stalker., Вы писали:
C>>Нет упоминаний о трассировке и метриках для профилирования. Нет упоминаний о мониторинге и тревожных сигналах. Нет упоминаний о стратегии обеспечения безопасности межсервисных вызовов или о механизмах передачи identity вызывающего. S>"пропаганда DTO-объектов и богатой доменной модели" есть везде, в том числе в whitepapers от Майкрософт т.к. без них написать современную систему невозможно.
Ещё как можно. И даже нужно — фаулерные системы превращаются в АДЪ очень быстро.
S>Я уже давно читал его книжки, но асинхронные методы, сетевые ошибки и прочее там вполне были.
Сейчас ещё раз просмотрел. Нету.
S>Даже про identity базовые на тот момент вещи (куки по-сути) там вроде упоминались, конечно про токены ничего не было, т.к. и самих токенов тогда еще не изобрели. Вообще сейчас сильный уклон в микросервисы, облака и SPA, которых тогда тоже не было, и про них уже достаточно много хорошей литературы.
Про identity там максимум было в разговорах про сессии.
S>Сами по себе паттерны от Фаулера вполне актуальны
Они, по большей части, антипаттерны. И да, актуальны.
Здравствуйте, Cyberax, Вы писали:
C>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?
Очень интересно, и если ты напишешь такую книгу, я буду одним из первых покупателей. Желательно с автографом автора
Кстати, а ничего подобного уже нет? Ты очень интересные темы затронул и мне подумалось, может уже что-то, пусть и не на 100% покрывающее эти вопросы, но уже есть?
