Зачем системному аналитику читать «Чистую архитектуру» Роберта Мартина

[psycho-coder]

Книга в первую очередь предназначена для архитектора решений, но будет полезна и разработчику.

Не соглашусь. Книга в первую очередь для разработчиков, так как архитектора еще надо найти, а код писать надо. Также надо понимать, что хочет архитектор, если уж его нашли. Погружение в проблематику, так сказать.

Роберт Мартин охватывает в книге 50+ лет опыта разработки

30+ лет: с конца 60-х по 90-е.

[smarkov]

Здравствуйте,

> Книга в первую очередь предназначена для архитектора решений, но будет полезна и разработчику
В этом предложении во главу поставил я поставил архитектора, потому что не каждый разработчик обязан заниматься архитектурой, что сложнее сказать об архитекторе. Говоря на тему какая роль, что должна выполнять я могу сослаться на классификацию 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й?

[psycho-coder]

1. Если опираться на тот же EPAM, то архитекторы там не занимаются там, что говорят разрабам как им писать код, где какие интерфейсы ставить и как их реализовывать. Об этом могу судить по интервью с архитектором EPAM. В книге же, даются базовые основы о том как правильно заниматься архитектурой приложения которое он пишет. На мой взгляд Solution Architect занимается немного другими делами.
Во, вспомнил, Software Architect, называется должность, когда архитектура строиться от кода.

2. Я имел ввиду не весь опыт Роберта, а только тот который описан в книге, там все заканчивается в 90х. Чем дальше занимался Дядюшка Боб я не в курсе.

[smarkov]

Речь не об этом интервью случайно? - https://www.youtube.com/watch?v=LhEVDvmm8SE

Если есть другое интервью, было бы интересно посмотреть

[psycho-coder]

Да, про него

[XaBoK]

Чем дальше (чем больше и сложнее системы), тем больше смежных областей необходимо понимать. Бизнес требования и техническое исполнение идут рука об руку ради оптимизации сроков и расходов.

[smarkov]

Работодателю выгодно, когда специалист совмещает несколько ролей. А для специалиста изучение смежной профессии, области - способ развиваться и повышать свою ценность

[igrkirillov]

По поводу Order и ActiveOrder. Не лучше ли сделать одну дто Order и в ней атрибут status (created, paid, cancelled и тп)? В итоге получится две ручки: 1) get /orders/{id} и 2) get /orders?onlyActive=true

[smarkov]

Ответ тут зависит от вопросов, которые есть выше в статье: «При дальнейших доработках наших методов оба объекта заказа будут развиваться одинаково?» или «Ответу одного метода потребуется один набор полей, а ответу другого метода — другой набор новых полей?», «Потребители методов getOrder и getActiveOrders одинаковые или разные?».

Например представим, что в вашей системе ActiveOrder потребляется только мобильным приложением для курьера, а Order клиентом бэк-офиса. Например бухгалтером. Наверняка курьеру важны одни атрибуты заказа - время доставки, адрес итд. А бухгалтеру совсем другие - стоимость, налог. Следовательно правильно было бы использовать разные DTO.

[igrkirillov]

Если курьеру нужны одни атрибуты, бухгалтеру - другие, тогда делаем enum Expansion (Courier, Accountant), далее клиент передаёт его в реквест-параметре, а сервер добавляет соотвествующие атрибуты в дто Order. Плюсы: меньше сущностей.

[psycho-coder]

Не всегда. В книге об этом говорится (или это в «чистом коде»?). Есть моменты которые могут казаться одинаковыми, но в дальнейшем их пути расходятся, и поэтому не стоит торопиться их объеденять. Как выше уже и ответили.

[igrkirillov]

Я понял, видимо, вы имеете в виду, когда совсем разного рода информация о заказе (курьерская, бухгалтерская, фискальная). Тогда понятно, это могут быть даже разные микросервисы: здесь точно разные ручки и разные дто. Но по статусам (активный, неактивный) дто я бы делить не стал :)

[igrkirillov]

По поводу фреймворков. В статье написано, что бизнес-логика не должна зависеть от фреймворка. На деле получается не так. Потому что, сначала выбирается фреймворк (Spring, OSGi и т.п.), а потом пишется бизнес-логика. Тоже самое с выбором платформы: Java, Python и т.п.

Но если бизнес-логика пошла вразрез с фреймворком, тогда выбираешь новый фреймворк и новый сервис пишешь на нём, а старый забываешь - обычно делаем так.

[smarkov]

В книге Роберт Мартин тоже упоминает про основополагающие фреймворки типа Spring'а. И подтверждает, что такие фреймворки сложно отнести на внешний слой архитектуры. Речь идет видимо о менее значимых фреймворках. Например о фреймворке для логирования. Его проще разделить интерфейсом от бизнес-логики, т.к. набор операций такого фреймворка ограничен и сводится лишь к записи в лог.

[psycho-coder]

Роберт довольно четко определяет отношение к фрейморкам в 32 главе «Фреймворк — это деталь». Одна глава не особо поможет, лучше почитать книгу ;)

[vialz]

Небольшое замечание - все же высокоуровневый дизайн обычно называют HLD, HAL обычно используют для hardware abstraction level

[smarkov]

Судя по цитируемости HLD вижу, что распространенный термин. Надо взять на вооружение