dusan

1. отдыхать. Т.е. высыпаться, гулять на свежем воздухе, делать простую работу полностью и с увлечением. (на словах очень просто, на деле сложно)
2. планировать свою учебу и чтение. Т.е. определить сколько время читаем или учимся. когда будет отдых. и т.д.
3. вероятно главный принцип эффективной учебы/чтения это пересмотр. почитали некую часть, отвернулись, вспомнили основные моменты. обдумали. Представили что кому-то объясняем эту тему. Ум должен увлекаться, прилипать к теме.
4. Планировать свои дела. Ум не должен быть нагружен работой по определению, что делать через минуту, как делать, где. и тд. постоянные такие вопросы просто его выматывают. И на нормальную умственную работу уже нет ментальных сил. Лучше уделить пол часа и запланировать на весь день. Даже если что-то пойдет не по плану.
5. Знать цель. Т.е. сознавать мотивацию. Для чего читаем, что хотим и т.д. Концентрацию в Индии примерно описывали так " представь что ты несешь чашу полную воды. Через площадь на которой толпа людей участвует в празднике. Крики шум и т.п. За тобой идет человек с топором. Если ты прольешь хотя бы каплю, то человек сразу отрубит тебе голову." Если приблизить к нашей жизни, то Зачем читать? Что будет если вникнуть в тему? Что будет если не изучить тему? Что будет если постоянно отвлекаться на соцсети и проч. Через неделю, год, десять лет.
еще советы: посмотреть Максима Дорофеева. Проблема современного человека не в том, что ему не хватает внимания, концентрации, энергии и проч. Проблема в том что он тратит внимание впустую. поверхностно. не вникая. Можно сказать он переконцентрирован, измотан концентрацией на совсем не нужных вещах.
Из медитации, посоветую випассану.

Enterprise разработка - это разработка, направленная на решение проблем бизнеса. В отличии от разработки для решения проблем конечных пользователей.

На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
* устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
* сложная и непостоянная бизнес-логика, давление на нее из множества источников
* результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
* слабо заметный вклад конкретного программиста, проистекает из сложности ПО

Требования к программисту... ну я бы сказал, усидчивость, вдумчивость, исполнительность... хм, а что, в каких-то других областях другие требования к программистам? Хотя, конечно, в противоположность, можно назвать способ разработки "быстро-быстро и в продакшн". Но, к слову, такие ситуации могут и в энтерпрайзе возникнуть.

По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.

Любой фреймворк с инверсией зависимостей подойдет. На Symfony и Yii2 точно можно сделать. На русскоязычном форуме Yii по теме DDD очень много обсуждений. Но если не увидели единого согласия по DDD, то скорее всего не читали книгу Эванса или Вернона. Если так, то лучше начать с кого-нибудь из них.

Многоуровневая архитектура рассказывает нам о слоях presentation, application, domain и infrastructure. С однонаправленным потоком данных. Нижестоящий слой, никогда не должен вызывать вышестоящий. Это значит, что к примеру можно выбросить presentation слой и не придется ничего изменять в оставшихся 3.

Фактически выходит, что в любой момент можно выбросить фреймворк и заменить другим, так как это presentation layer в многоуровневой архитектуре. Можно даже сначала написать application/domain, проверить их юнит-тестами, а только потом уже задуматься о фреймворке. Application/domain слои никогда ни при каких обстоятельствах не должны вызывать методы фреймворка. Контроллеры фреймворка работают с доменной моделью, через вызовы методов application layer.

Соответственно, при миграции на другой фреймворк, всё что потребуется, это переписать контроллеры (методы очень простые 1-5 строк) и реализации классов в infrastructure layer если вы завязывали их на фреймворк. Хотя лично я бы, не советовал этого делать. Лучше найти/написать отдельные библиотеки/компоненты под инфраструктурный слой, тем самым облегчив себе жизнь в будущем, когда фреймворк умрет или при очередном релизе мажорной версии.

Symfony под DDD наилучший выбор, он компонентный, можно подтянуть только то, что нужно. С другой стороны Yii2, он монолитный и вы затяните Active Record и кучу всего еще, чем не будете пользоваться, но джуниор придет и обязательно понавызывает AR или чего-нибудь еще в application/domain слоях, чего вы явно не ожидаете. Поэтому в случае с Yii2 нужен будет тотальный контроль. :)

Про Laravel не пишу ничего, так как не работал с ним. Но судя по беглому просмотру документации, никаких проблем сделать на нем DDD также нет.