Фаулер. Архитектура
От: BlackEric http://black-eric.lj.ru
Дата: 24.07.19 09:18
Оценка: :))
Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?
https://github.com/BlackEric001
Re: Фаулер. Архитектура
От: Дельгядо Филипп Россия  
Дата: 24.07.19 10:48
Оценка: +10
Здравствуйте, BlackEric, Вы писали:

BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?


А какое отношение к архитектуре имеют мобильные приложения и выбор протокола сериализации приложения?
Это все совершенно несущественные частности...
Re[2]: Фаулер. Архитектура
От: Буравчик Россия  
Дата: 24.07.19 11:01
Оценка:
Здравствуйте, Дельгядо Филипп, Вы писали:

ДФ>А какое отношение к архитектуре имеют мобильные приложения и выбор протокола сериализации приложения?

ДФ>Это все совершенно несущественные частности...

С чего ты вдруг решил, что для его приложения это несущественные частности?

Что имеет отношение к архитектуре?
Best regards, Буравчик
Отредактировано 24.07.2019 11:03 Буравчик . Предыдущая версия .
Re[2]: Фаулер. Архитектура
От: BlackEric http://black-eric.lj.ru
Дата: 24.07.19 11:54
Оценка: +1
Здравствуйте, Дельгядо Филипп, Вы писали:


ДФ>А какое отношение к архитектуре имеют мобильные приложения и выбор протокола сериализации приложения?


Протокол сериализации, да, частность, хотя такая, что потом будет влиять на все.

А обпеспечение взаимодействия с мобильным приложение — однозначно должно закладываться в архитектуре. Для него необходимо выставлять АПИ. Для обеспечения единоообразия это же апи по хорошему должен использовать и веб интерфейс.
https://github.com/BlackEric001
Re: Фаулер. Архитектура
От: kaa.python Сингапур http://sysdev.me/
Дата: 24.07.19 12:09
Оценка: 7 (2) +1
Здравствуйте, BlackEric, Вы писали:

BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?


Думаю что для начала нужно определиться с тем, что же такое архитектура, а уже потом говорить о книгах. Архитектура, это не про мобильное приложение и не про десктопное и не про xml vs json. Арихтектура даже не про бэкенд или фронтенд. Архитектура это про программно-аппаратный комплекс, который решает бизнес задачи. Именно комплекс, который нацелен на решения задач бизнеса/пользователя.

В то же время дизайн — это как раз про xml vs json, мобильные приложения, бэкенд, фронтенд, реляционные базы VS k/v хранилища. Само собой, пересечение между архитектурой и дизайном есть и оно огромное, но акценты в обоих случаях сильно разные.

Поэтому, если хочется чего-либо про архитектуру, то надо читать классику, а именно Software Architecture in Practice. Если же нужен в первую очередь дизайн, то, безусловно The Architecture of Open Source Applications.
Re[2]: Фаулер. Архитектура
От: BlackEric http://black-eric.lj.ru
Дата: 24.07.19 12:12
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Поэтому, если хочется чего-либо про архитектуру, то надо читать классику, а именно Software Architecture in Practice. Если же нужен в первую очередь дизайн, то, безусловно The Architecture of Open Source Applications.


Вот только в названии в обоих случаях Architecture. Надо подумать где разница между дизайном и архитектурой.
https://github.com/BlackEric001
Re[3]: Фаулер. Архитектура
От: kaa.python Сингапур http://sysdev.me/
Дата: 24.07.19 12:25
Оценка:
Здравствуйте, BlackEric, Вы писали:

BE>Вот только в названии в обоих случаях Architecture. Надо подумать где разница между дизайном и архитектурой.


Насколько я помню Architecture in Practice, там как раз есть размышления на тему отличия архитектуры от дизайна с которыми я полностью согласен и привел выше. Да и если посмотреть на вакансии архитекторов то видно, что архитектура, обычно — это про весь комплекс в целом, как минимум на уровне подразделения компании.
Re[3]: Фаулер. Архитектура
От: Vladek Россия Github
Дата: 24.07.19 14:44
Оценка:
Здравствуйте, BlackEric, Вы писали:

BE>Протокол сериализации, да, частность, хотя такая, что потом будет влиять на все.


BE>А обпеспечение взаимодействия с мобильным приложение — однозначно должно закладываться в архитектуре. Для него необходимо выставлять АПИ. Для обеспечения единоообразия это же апи по хорошему должен использовать и веб интерфейс.


Это не архитектура, а интеграция.

https://en.wikipedia.org/wiki/Enterprise_application_integration
http://files.rsdn.org/43395/hr-kyle-theisen-04.png
Re: Фаулер. Архитектура
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.07.19 15:25
Оценка: +3
Здравствуйте, BlackEric, Вы писали:

BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?


Мне кажется что если выбор xml vs json на что-то влияет, то архитектура плохая.
А вот про мобильные клиенты и оффлайн действительно у фаулера ничего нет, тогда все было по-другому.

Что читать — About face Алана Купера (Проектирование интерфейсов), там для архитектора приложений полезных сведений гораздо больше, чем в любой книге по арихеткруте и дизайну.
Re: Фаулер. Архитектура
От: Cyberax Марс  
Дата: 25.07.19 00:26
Оценка: +2
Здравствуйте, BlackEric, Вы писали:

BE>Книга Фаулера, как по мне, уже местами устарела. Там нет ничего про мобильные клиенты и выбора xml vs json как минимум. Есть ли что-нибудь по-новее?

Из собственного опыта — читаем что написано у Фаулера и делаем 100% наоборот.
Sapienti sat!
Re[2]: Фаулер. Архитектура
От: kaa.python Сингапур http://sysdev.me/
Дата: 25.07.19 02:34
Оценка: 1 (1) +2
Здравствуйте, Cyberax, Вы писали:

C>Из собственного опыта — читаем что написано у Фаулера и делаем 100% наоборот.


Этой книги Фаулера я вроде не читал, но мнение очень интересное. Не затруднит 1-2 примера привести? Очень заинтриговал
Re[3]: Фаулер. Архитектура
От: Cyberax Марс  
Дата: 25.07.19 05:59
Оценка: 40 (4) +1
Здравствуйте, kaa.python, Вы писали:

C>>Из собственного опыта — читаем что написано у Фаулера и делаем 100% наоборот.

KP>Этой книги Фаулера я вроде не читал, но мнение очень интересное. Не затруднит 1-2 примера привести? Очень заинтриговал
Например, пропаганда DTO-объектов, богатой доменной модели и мусора типа "стратегий". Совершенно не упомянуто об асинхронной модели, для долгоиграющих операций. Мелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был.

Что нельзя простить — совершенно бездарное описание работы удалённых сервисов, оно там в худшем стиле начала 90-х. Почти ни один из его примеров не пройдёт review у меня: нет обработки сетевых ошибок и retry, нет стратегии обеспечения идемпотентности, нет анализа на поведение при ошибках downstream-сервисов и т.д.

Нет упоминаний о трассировке и метриках для профилирования. Нет упоминаний о мониторинге и тревожных сигналах. Нет упоминаний о стратегии обеспечения безопасности межсервисных вызовов или о механизмах передачи identity вызывающего.

В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?
Sapienti sat!
Re[4]: Фаулер. Архитектура
От: Буравчик Россия  
Дата: 25.07.19 08:13
Оценка: 1 (1) +1
Здравствуйте, Cyberax, Вы писали:

C>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?


На книгу редко у кого времени хватает. Хотя бы начать с серии статей — было бы здорово.
Best regards, Буравчик
Re[4]: отделять "веб север" от "сервера приложений"
От: Sharov Россия  
Дата: 25.07.19 08:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>НМелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был.


А что тут не так? Почему отделять плохо?
Кодом людям нужно помогать!
Re[5]: отделять "веб север" от "сервера приложений"
От: Буравчик Россия  
Дата: 25.07.19 09:06
Оценка:
Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Cyberax, Вы писали:


C>>НМелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был.


S>А что тут не так? Почему отделять плохо?


Наверное, про то, что сейчас API в серверах приложений строится практически всегда с использованием HTTP. Т.е. серверы приложений являются веб-серверами.
Best regards, Буравчик
Re[4]: Фаулер. Архитектура
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 25.07.19 09:46
Оценка: +2
Здравствуйте, Cyberax, Вы писали:


C>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?

А напиши, серьёзно. Вангую, заработаешь ещё 1кк$
Sic luceat lux!
Re[5]: отделять "веб север" от "сервера приложений"
От: Cyberax Марс  
Дата: 25.07.19 16:18
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

C>>НМелочи типа рекомендаций отделять "веб север" от "сервера приложений" можно простить, всё-таки 2006-й год был.

S>А что тут не так? Почему отделять плохо?
В 2006-м году веб-сервер был отдельной фигнёй, которая выдавала динамический HTML в ответ на запросы пользователей.

Сейчас корпоративные приложения на 90% построены в виде статических JS/HTML/CSS модулей, которые загружаются с какого-либо CDN. Затем этот JS уже просто напрямую вызывает backend'овые сервисы. Т.е. классический динамический веб-сервер как таковой часто вообще отсутствует.
Sapienti sat!
Re[4]: Фаулер. Архитектура
От: Stalker. Австралия  
Дата: 25.07.19 23:16
Оценка: -2
Здравствуйте, Cyberax, Вы писали:

C>Что нельзя простить — совершенно бездарное описание работы удалённых сервисов, оно там в худшем стиле начала 90-х. Почти ни один из его примеров не пройдёт review у меня: нет обработки сетевых ошибок и retry, нет стратегии обеспечения идемпотентности, нет анализа на поведение при ошибках downstream-сервисов и т.д.


C>Нет упоминаний о трассировке и метриках для профилирования. Нет упоминаний о мониторинге и тревожных сигналах. Нет упоминаний о стратегии обеспечения безопасности межсервисных вызовов или о механизмах передачи identity вызывающего.


"пропаганда DTO-объектов и богатой доменной модели" есть везде, в том числе в whitepapers от Майкрософт т.к. без них написать современную систему невозможно. Я уже давно читал его книжки, но асинхронные методы, сетевые ошибки и прочее там вполне были. Даже про identity базовые на тот момент вещи (куки по-сути) там вроде упоминались, конечно про токены ничего не было, т.к. и самих токенов тогда еще не изобрели. Вообще сейчас сильный уклон в микросервисы, облака и SPA, которых тогда тоже не было, и про них уже достаточно много хорошей литературы. Сами по себе паттерны от Фаулера вполне актуальны
Re[5]: Фаулер. Архитектура
От: Cyberax Марс  
Дата: 26.07.19 00:19
Оценка: +2
Здравствуйте, Stalker., Вы писали:

C>>Нет упоминаний о трассировке и метриках для профилирования. Нет упоминаний о мониторинге и тревожных сигналах. Нет упоминаний о стратегии обеспечения безопасности межсервисных вызовов или о механизмах передачи identity вызывающего.

S>"пропаганда DTO-объектов и богатой доменной модели" есть везде, в том числе в whitepapers от Майкрософт т.к. без них написать современную систему невозможно.
Ещё как можно. И даже нужно — фаулерные системы превращаются в АДЪ очень быстро.

S>Я уже давно читал его книжки, но асинхронные методы, сетевые ошибки и прочее там вполне были.

Сейчас ещё раз просмотрел. Нету.

S>Даже про identity базовые на тот момент вещи (куки по-сути) там вроде упоминались, конечно про токены ничего не было, т.к. и самих токенов тогда еще не изобрели. Вообще сейчас сильный уклон в микросервисы, облака и SPA, которых тогда тоже не было, и про них уже достаточно много хорошей литературы.

Про identity там максимум было в разговорах про сессии.

S>Сами по себе паттерны от Фаулера вполне актуальны

Они, по большей части, антипаттерны. И да, актуальны.
Sapienti sat!
Re[4]: Фаулер. Архитектура
От: kaa.python Сингапур http://sysdev.me/
Дата: 26.07.19 02:11
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В общем, современная сервисная архитектура — это вообще отдельная и сложная тема. Хм. А не написать ли мне книгу про это?


Очень интересно, и если ты напишешь такую книгу, я буду одним из первых покупателей. Желательно с автографом автора

Кстати, а ничего подобного уже нет? Ты очень интересные темы затронул и мне подумалось, может уже что-то, пусть и не на 100% покрывающее эти вопросы, но уже есть?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.