#структурный_дизайн — Public Fediverse posts

Про архитектуру приложений для тех кому мало Чистой архитектуры

Помню, когда я был джуном и даже миддлом, меня очень волновал вопрос: как же должна выглядеть структура приложения по умным книжкам и всяким бест-практисам. На тот момент я уже повидал разные варианты архитектур, и все они выглядели корявыми, нелогичными, возникшими спонтанно из чьих-то костылей. Лет пять назад я обнаружил для себя Чистую архитектуру Дяди Боба и на некоторое время успокоился, пока поток новых источников постепенно не начал менять мое отношение и к этой книге. Но, если вы решили для себя, что Чистая архитектура - это ваш окончательный выбор, то я точно не буду вас отговаривать, потому что, на мой взгляд, это однозначно лучше, чем, наверное, 90% того, что вам встретится на рынке. Впрочем, эта статья для тех, кому этого не достаточно: для тех, кто хочет глубже понимать эволюцию мысли в области дизайна приложений, основные вызовы и идеи. Раньше мы в 3 частях [ 1 , 2 , 3 ] пробежались по основным идеям архитектуры систем. Поэтому, если вы ищете информацию по System Design, микросервисам и топологии команд, то вам туда. Эта же статья про архитектуру внутри кодовой базы: она посвящена концепциям программирования, влияющим на структуру приложения, поэтому описывает не только архитектурные подходы, но и иные идеи, оставляющие на дизайне свой отпечаток.

https://habr.com/ru/articles/931866/

#ООП #функциональное_программирование #рефакторинг #гексагональная_архитектура #шаблоны_проектирования #структурный_дизайн #yagni #domaindriven_design

Структурный дизайн. Древний секрет простого и быстрого кода

Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код. В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше. Например, в чистом коде я до сих пор не знаю способа за конечное время дать ответ на вопрос «Сколько уровней абстракции в этой функции?». А если взять DDD — то я до сих пор не знаю способа, который бы позволял стабильно и за конечное время находить границы между ограниченными контекстами (прошу прощения за каламбур) или агрегатами. Эта неопределённость ведёт к длительным дискуссиям на ревью и в голове разработчика о том, какой из способов является наилучшим для решения задачи. А после этих дискуссий, каждый из участников (включая того дилетанта в собственной голове) остаётся при своём мнении. Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял. Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет. В этом посте я даю краткий экскурс в идею сбалансированной формы системы из структурного дизайна и рассказываю на примере трёх кейсов о результатах применения этой идеи в моей коммерческой практике.

https://habr.com/ru/companies/jugru/articles/858418/

#структурный_дизайн #функциональное_программирование #функциональная_архитектура