bocharovf Sep 11 2017 at 17:25

Архитектурная пирамида приложения

8 min

20K

System Analysis and Design*ООP*Programming*Designing and refactoring*Perfect code*

+17

Comments 15

ahmpro Sep 11 2017 at 19:08

Прошу прощения, но имхо это какая-то графомания. Намешали всего в кучу и для красоты обернули в пирамиду.
Возможно я не до конца понял вашу идею, но я не могу сходу однозначно расположить предложенные термины в пирамиду, они просто не выстраиваются так ровно.

bocharovf Sep 11 2017 at 21:48

Намешали всего в кучу

Куча — это что-то неупорядоченное. А тут как раз наоборот — выстраивается иерархия.
У вас какие-то конкретные возражения по расположению уровней/элементов или Вы против идеи «иерархичности» в целом?

napa3um Sep 11 2017 at 23:24

У вас в пирамиде располагаются колесо, разметка дороги, коробка передач, первое начало термодинамики и гаишник.

flancer Sep 12 2017 at 07:52

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

napa3um Sep 12 2017 at 07:56

Вы путаете целесообразную аналитику с праздным резонёрством и апофенией. Уверяю вас.

flancer Sep 12 2017 at 08:25

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

napa3um Sep 12 2017 at 08:29

Не много на себя взяли? Огласите, плиз, критерии, по которым вы будете оценивать мой ответ. Для независимой проверки ваших выводов относительно пригодности моего комментария.

flancer Sep 12 2017 at 08:41

Нет, не много. Просто узнал, можно ли относится к вашим уверениям "Вы путаете целесообразную аналитику с праздным резонёрством и апофенией" серьезно или это очередное бла-бла-бла. Спасибо, узнал.

bocharovf Sep 12 2017 at 08:00

Все, что располагается в пирамиде, участвует (влияет) на архитектуру приложения. Да, элементы очень разные, но это не значит, что их нельзя сравнивать между собой. В статье приведена логика, по которой эти принципы расположены один над другим. Вы можете соглашаться или не соглашаться с этой логикой.
Лично мне такая структура помогает принимать решения (см. чек-лист). Надеюсь, она окажется полезной и другим.

napa3um Sep 12 2017 at 08:02

Забыли завтрак программистов добавить в пирамиду и кактус на мониторе. Всё влияет, везде есть связи, кто ж спорит, мир един.

KeyJoo Sep 12 2017 at 07:35

Я б, в строители пирамид* пошёл, пусть меня научат…
Умение свести всё к единой структуре, от которой будет польза — это уже половина пройденного пути. Я только за+, чтобы побольше было такого рода синтеза. Хотя в пирамиде слои вначале что-то смутили (их очередность). Но чек-лист взял своё!

archik Sep 12 2017 at 09:51

В пирамиде и в заголовке есть аббревиатура DDD, однако она нигде не расшифровывается и никак не упомянается. Зачем вы так обижаете Эрика Эванса и Domain-Driven-Design? :)

Sinatr Sep 12 2017 at 10:06

шутка про слона, которого нужно есть по частям

какая шутка?

KeyJoo Sep 12 2017 at 11:04

Я бы этого слона тоже в пирамиду запихнул, в слой методологий.

ghost404 Sep 12 2017 at 23:34

Немножко странная схема получилась и чек-лист тоже.

DDD напрямую связана с бизнес логикой. Соответственно слой с DDD должен идти сразу за слоем "Бизнес-требования" и до всяких там KISS и YAGNI.
Вы даже в статье говорите, что IoC связан с фреймворком. И как же оно будет прыгать через 2 уровня?
DIP это не только зависимости ваших компонентов друг от друга, но и зависимости от фраймвора и библиотек. То есть, по идее, правильней сформулировать, что DIP это уровень между вашим компонентом и окружением в роли которого выступает фраймворк и библиотеки.
Уровни "Расширение" и "Связанность" скорей относятся к особенностям реализации компонента. Я бы скорей выделял уровень "Реализация" с вложенными в него уровнями "Расширение" и "Связанность" между частями реализуемого компонента, а сверху над ним уровень DIP, связывания компонента с окружением.
Методологии TDD и BDD я бы вынес вообще куда-то в сторонку. Это относится скорее к методам написания кода. Это примерно тоже самое, что включить в пирамиду уровень "Редактор" (IDE, Vim, Блокнот). Редакторы тоже будут влиять на время и стоимость разработки. Я конечно утрирую, но все равно непонятно почему они находятся над DIP, LSP и прочими.

В чек-лист меня смущает порядок пунктов и путаница со временем/состоянием.

7. Не противоречат ли мои изменения выбранной мной методологии?

То есть вы уже сделали изменение и проверяете сделали ли вы его по TDD?

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

Почему вы решаете вопросы совместимости после выполнения работы?

9. Могут ли использованные мной библиотеки решить поставленную подзадачу?

А если не могут, то что вы писали все это время решая поставленную задачу?

1. Реализуемы ли мои изменения с учетом отведенного мне бюджета, времени и прочих объективных ограничений?

А здесь вы говорите об исполнении задачи в будущем.

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

Я могу и ошибаться в суждениях. Сколько людей столько и мнений. В любом случае, спасибо за проделанную работу.