В книге Роберт Мартин тоже упоминает про основополагающие фреймворки типа Spring'а. И подтверждает, что такие фреймворки сложно отнести на внешний слой архитектуры. Речь идет видимо о менее значимых фреймворках. Например о фреймворке для логирования. Его проще разделить интерфейсом от бизнес-логики, т.к. набор операций такого фреймворка ограничен и сводится лишь к записи в лог.
Ответ тут зависит от вопросов, которые есть выше в статье: «При дальнейших доработках наших методов оба объекта заказа будут развиваться одинаково?» или «Ответу одного метода потребуется один набор полей, а ответу другого метода — другой набор новых полей?», «Потребители методов getOrder и getActiveOrders одинаковые или разные?».
Например представим, что в вашей системе ActiveOrder потребляется только мобильным приложением для курьера, а Order клиентом бэк-офиса. Например бухгалтером. Наверняка курьеру важны одни атрибуты заказа - время доставки, адрес итд. А бухгалтеру совсем другие - стоимость, налог. Следовательно правильно было бы использовать разные DTO.
Работодателю выгодно, когда специалист совмещает несколько ролей. А для специалиста изучение смежной профессии, области - способ развиваться и повышать свою ценность
> Книга в первую очередь предназначена для архитектора решений, но будет полезна и разработчику В этом предложении во главу поставил я поставил архитектора, потому что не каждый разработчик обязан заниматься архитектурой, что сложнее сказать об архитекторе. Говоря на тему какая роль, что должна выполнять я могу сослаться на классификацию EPAM, т.к. у этой компании опубликованы некоторые грейды. Вот например у разработчика "able to create design, technical and project documentation" начинается лишь с L3.Senior. См. https://github.com/gm-soft/knowledge-base/blob/master/management/2019-09-08-developer-skill-matrix.md#software-developer-skill-matrix-epam
Соглашусь, что книга действительно очень полезна разработчику. Да и вопрос, для кого книга больше предназначалась, по-моему дискуссионный
>Роберт Мартин охватывает в книге 50+ лет опыта разработки Процитирую книгу: "Свою первую строку кода я написал в 1964 году, в 12 лет. Сейчас на календаре 2016-й, то есть я пишу код уже больше полувека." У вас есть какая-то более подробная информация, чем он занимался с 90х по 2016й?
Soapui запускался с ноутбука и доводы, которые вы привели действительно важные. Но в моем случае они скорей всего не актуальны по следующим причинам:
Я выставлял на том же приложении статическую страницу и получал по ней несколько десятков rps
Загрузка процессора в службе приложения была близкой к максимуму. Можно посмотреть на сравнительной таблице выше в статье
Может ли быть, что производительность по статической странице выполнялось в ограниченном количестве tcp/ip соединений. Думаю да. Но загрузка процессора службы приложений говорит, что дело в загрузке процессора на серверной стороне.
Ну и просто для информации: SoapUI не закрывает tcp/ip соединение пока не закончит весь тест. Но на сколько помню, это можно параметризировать
В вашем ответе есть что растащить на Гугл-запросы) спасибо за такой развернутый ответ) БД MS SQL выбрана как наиболее знакомая мне из майкрософтовского стэка, служба приложений маячила перед глазами при изучении Azure
@Zaphkiel@Drag13производительность безусловно низкая. Под капотом EntityFramework, которым я пользуюсь в первый раз, ну и в целом программирование для меня это хобби. Поэтому тут проблемы не в Azure, а в не оптимальном коде. Его я собираюсь пересмотреть и улучшить. А сейчас по крайней мере я смог сравнить тарифы между собой и попробовать разные стратегии тестирования на Azure
Обыскался в статье class
YandexAliceRequest, но так и не нашелСудя по цитируемости HLD вижу, что распространенный термин. Надо взять на вооружение
Речь не об этом интервью случайно? - https://www.youtube.com/watch?v=LhEVDvmm8SE
Если есть другое интервью, было бы интересно посмотреть
В книге Роберт Мартин тоже упоминает про основополагающие фреймворки типа Spring'а. И подтверждает, что такие фреймворки сложно отнести на внешний слой архитектуры. Речь идет видимо о менее значимых фреймворках. Например о фреймворке для логирования. Его проще разделить интерфейсом от бизнес-логики, т.к. набор операций такого фреймворка ограничен и сводится лишь к записи в лог.
Ответ тут зависит от вопросов, которые есть выше в статье: «При дальнейших доработках наших методов оба объекта заказа будут развиваться одинаково?» или «Ответу одного метода потребуется один набор полей, а ответу другого метода — другой набор новых полей?», «Потребители методов getOrder и getActiveOrders одинаковые или разные?».
Например представим, что в вашей системе ActiveOrder потребляется только мобильным приложением для курьера, а Order клиентом бэк-офиса. Например бухгалтером. Наверняка курьеру важны одни атрибуты заказа - время доставки, адрес итд. А бухгалтеру совсем другие - стоимость, налог. Следовательно правильно было бы использовать разные DTO.
Работодателю выгодно, когда специалист совмещает несколько ролей. А для специалиста изучение смежной профессии, области - способ развиваться и повышать свою ценность
Здравствуйте,
> Книга в первую очередь предназначена для архитектора решений, но будет полезна и разработчику
В этом предложении во главу поставил я поставил архитектора, потому что не каждый разработчик обязан заниматься архитектурой, что сложнее сказать об архитекторе. Говоря на тему какая роль, что должна выполнять я могу сослаться на классификацию EPAM, т.к. у этой компании опубликованы некоторые грейды. Вот например у разработчика "able to create design, technical and project documentation" начинается лишь с L3.Senior. См. https://github.com/gm-soft/knowledge-base/blob/master/management/2019-09-08-developer-skill-matrix.md#software-developer-skill-matrix-epam
Соглашусь, что книга действительно очень полезна разработчику. Да и вопрос, для кого книга больше предназначалась, по-моему дискуссионный
>Роберт Мартин охватывает в книге 50+ лет опыта разработки
Процитирую книгу: "Свою первую строку кода я написал в 1964 году, в 12 лет. Сейчас на календаре 2016-й, то есть я пишу код уже больше полувека." У вас есть какая-то более подробная информация, чем он занимался с 90х по 2016й?
Добрый день, спасибо за коммент,
Soapui запускался с ноутбука и доводы, которые вы привели действительно важные. Но в моем случае они скорей всего не актуальны по следующим причинам:
Я выставлял на том же приложении статическую страницу и получал по ней несколько десятков rps
Загрузка процессора в службе приложения была близкой к максимуму. Можно посмотреть на сравнительной таблице выше в статье
Может ли быть, что производительность по статической странице выполнялось в ограниченном количестве tcp/ip соединений. Думаю да. Но загрузка процессора службы приложений говорит, что дело в загрузке процессора на серверной стороне.
Ну и просто для информации: SoapUI не закрывает tcp/ip соединение пока не закончит весь тест. Но на сколько помню, это можно параметризировать
В вашем ответе есть что растащить на Гугл-запросы) спасибо за такой развернутый ответ) БД MS SQL выбрана как наиболее знакомая мне из майкрософтовского стэка, служба приложений маячила перед глазами при изучении Azure
@Zaphkiel@Drag13производительность безусловно низкая. Под капотом EntityFramework, которым я пользуюсь в первый раз, ну и в целом программирование для меня это хобби. Поэтому тут проблемы не в Azure, а в не оптимальном коде. Его я собираюсь пересмотреть и улучшить. А сейчас по крайней мере я смог сравнить тарифы между собой и попробовать разные стратегии тестирования на Azure