Пустой дистрибутив. Абсолютно любое действие в нём начинается с tar zxf, configure, make install. Разговоры о его надежности заканчивается через полчаса после необходимости поставить какой-нибудь htop или monit. Ещё через час после разломанного в крошево дистрибутива заканчиваются рассказы о том, что существуют какие-то внешние репозитории, в которых что-то есть.
Фичи формируют контексты (boundary context). Контексты пересекаются но в целом весьма изолированы. Их нутро не зависит друг от друга.
Возьмем к примеру каталог товаров и прикинем какие у нас тут есть контексты:
В этом примере наиболее интересный «модуль» — это поиск. Он может искать для нас продукты в каталоге и ордеры. Но они ничего не знает о ордерах или продуктах. Скажем когда мы ищем ордеры — мы просим модуль поиска найти для нас «ордеры» и он всего-лишь вернет нам айдишки и информацию которая важна нам для поиска. Далее для этих айдишек мы можем уже запросить детали у модуля каталога.
Синхронизация этих модулей — ивенты. Кто-то обновил продукт — кидаем ивент — синхронизируем данные в других контекстах.
Профит тут в том что мы можем отдельно посадить чувака заниматься поиском, и отдельно чувака заниматься ордерами. Можем перевести поиск на свою СУБД которая хорошо умеет полнотекстовый поиск (например эластика). И при этом если у нас добавляются фичи в каталог — это не сильно влияет на поиск.
https://habrahabr.ru/company/englishdom/blog/328550/
Гибкость — это когда нет зависимости между моделей данных, бизнес логикой, поведением и местом хранения данных.
https://habrahabr.ru/post/327746/
Перестаньте выносить повторяющийся код. Дублирование кода — это нормально. Особенно в контроллерах. Когда мы говорим про DRY многие забывают про Try. Далеко не все дублирование нужно устранять. В целом мотивация этого действа весьма простая — если в коде будут баги и этот код дублируется — то надо править в нескольких местах. Однако с другой стороны, когда речь идет про такие вещи как контроллеры, которые декларируют последовательность действий, очень удобно когда весь флоу прописан последовательно и прочитать его можно без прыжков между файлами. А еще веселее становится после того, как через месяц после устранения дублирования вдруг оказывается что «некоторые штуки то оказывается были просто похожи но не являлись дублированием». И разворачивать всю эту штуку уже не так приятно. Та же история и с «поведениями» для Yii. Они конечно здорово и весело, но при определенном масштабе создают сложности для понимания кода.
Так что перед тем как устранять дублирование такими примитивными механизмами как трейты, следует задуматься:
https://habrahabr.ru/post/326960/#comment_10200012
Очень старая (2005 год) статья от Петра Зайцева (Percona) о конвертировании MyISAM таблиц в InnoDB
http://peter-zaitsev.livejournal.com/6154.html
Are there any performance benefits with Innodb tables when ? Yes there are, even if you forget about support
of transactions, row level locking and consistent reads. Innodb tables are clustered by PRIMARY KEY. This
means a lot of overhead for writes but PRIMARY KEY reads could be twice as fast compared to MyISAM tables for
disk bound loads. To retrieve the row by PRIMARY KEY MyISAM normally needs 2 reads, while Innodb only one.
If you have table small enough to fit in memory there are more benefits — Innodb caches both data and index
in memory, while MyISAM caches only index, using OS cache for caching data, which means Innodb can have much
better performance especially for Random IO (joins), moreover Innodb builds hash indexes in the buffer pool based on
BTREE indexes, which speeds up lookups even further. This all makes Innodb up to 3 times faster for some heavy join
queries, when data is in memory. Even if tables do not fit in memory you get asynchronous read-ahead and asynchronous
dirty buffers flush which is helpful in some cases.