Ход мыслей при объектно-ориентированном анализе.

нужно бизнес логику переплетать со сложным пользовательским интерфейсом и REST API

[подавился чаем] нужно?

Кому не лень поделитесь пожалуйста своим алгоритмом анализа предметной области.

Декомпозиция задачи — вот и весь алгоритм анализа :)

Особенно если нужно бизнес логику переплетать со сложным пользовательским интерфейсом и REST API.

Клиент просто дергает что-либо из сервиса/моделей/etc. Как это взаимосвязано, слабо представляется.

Куча мастхев книг не помогают.

Точно, а дзен от ЛОР-ца поможет :) Книги по архитектуре приложений надо читать, так или иначе. Но не каждая макулатура есть литература. Приведите конкретные примеры того, что читали. Станет ясно в чем проблема.

Так абстрактно каждый своё поймёт. Нарисуй задачу.

https://www.youtube.com/watch?v=_Kex5hwGE-w
https://www.youtube.com/watch?v=6m4XPje76WU

Декомпозиция задачи

Плюс отдел методологии. Вот и всё.

PS. Я за свою практику нормальных архитекторов не встречал, увы. Вечно все оканчивается 4-5 схемами на А0, которые через год устаревают и вообще хер проссышь что там изначально было.

Не в коде, это я образно. Так-то понятно, что не нужно. Вот только нужно это красиво делать.

которые через год устаревают

Если у проекта жизненный цикл не планировался дольше чем на год, то это нормально, если жизненный цикл планировался на 10 лет, а архитектура устарела через год, то, скорее всего, проектировщик забыл принять свои таблетки.

Вечно все оканчивается 4-5 схемами на А0

Ну если это не черновик, то на 4-5 листов А0 мелко и аккуратно можно нанести довольно большой объем информации. А что, это еще делается на бумаге? :)

вообще хер проссышь что там изначально было

Бывают сложные проекты, в которых сходу и нельзя разобраться. На то они и сложные :)

Гради Буча, Фаулера, Роберта Мартина, GoF и прочие из серий Head First. В голове много инфы, но что-то если начать это применять, получается каша из классов и связей между ними.

А что, это еще делается на бумаге? :)

Это делается в десятке тулзов, начиная от visio и заканчивая графвизом с реверс-инженерингом базы, например.

проектировщик забыл принять свои таблетки.

Ёпрст, об чем и речь. ТСу просто решить надо - он или рядовой разработчик, или топит за архитектора.

Я вот вообще тупо в тетрадке все прикидываю, мне хватает. Дальше - более предметно можно частности по конкретной задаче раскидать.

«конкретной задаче» читай «конкретным задачам»

Уже выше сказали. Приведите конкретный пример. (типа «Есть область А. В ней можно выделить сущности a/b/c/d/etc, связи» и т.д. и т.п.) Или хотя бы просто опишите задачу словами, хочу то-то и то-то. Тогда уже можно будет давать какие-либо конкретные советы.

Да, есть элементарные правила, которые должны подразумеваться, типа «Преждевременная оптимизация — зло», и т.д., но эти вещи вы итак знаете если читали литературу выше. Просто вам сложно начать, а переходить от теории к практике всегда сложно. Глаза боятся — руки делают. Просто начните, но не пытайтесь сразу сделать конфетку, ошибаться в некоторых случаях полезно.

Литературу я критиковать не буду, для этого есть отдельная закрепленная тема, там можно спросить, скажу только что толку от молотка нет, если нет понимания что вы хотите им сделать.
P.S.: и не всегда инструментом получается пользоваться прямо вот так вот сразу :)
http://s1.developerslife.ru/public/images/gifs/ee930de5-066d-4a1e-9510-8388e6...

Короче как делать крутые архитектурные решения.

Берешь крутого архитектора, он делает тебе крутые архитектурный решения...

Зачетные презенташки. Есть еще что поучительное, по теме или близко к этому?

Вот ещё в закладочках лежит, не добрался пока посмотреть https://habrahabr.ru/company/jugru/blog/191946/

и вот https://habrahabr.ru/post/153225/

не пытайтесь сразу сделать конфетку

Очень верное замечание, которое тоже можно отнести к «преждевременной оптимизации». Во-первых, всё равно придётся переделывать. А во-вторых, гораздо полезнее сперва сделать криво-косо работающий набросок, откуда уже потом будет видно в какую сторону идти. И даже, чем тупее и проще будет рабочая модель, тем «понятнее» будет предмет.