Интернет-магазины автозапчастей - не так просто как кажется

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

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

Требовалось кое-то простое и гибкое решение позволяющее решать сложные задачи и держать простоту разработки на нужном уровне. Мы стали пробовать собирать разные варианты архитектурных решений, упирались в проблемы и искать пути решения, находить ответы в книгах.
Книга Масштабирование приложений, Ли Атчисон. Определила точно проблему:
— Сложность — враг стабильности. Чем сложнее становится система, тем менее она стабильна. Хотя ваши приложения растут и становятся все более сложными, старайтесь придерживать простату при проектировании
архитектуры и разработке приложения, его безопасности и низких уровней риска.

Также одна из книг ответила на многие вопросы это книга Роберта Мартина "Чистая архитектура". Ее основной посыл:
— Ваше приложение не должно зависеть от инфраструктуры, база данных, внешний вид, это все вторично, на первом месте должна быть модель предметной области.

И в конечном счете тропинка привела к книге Ворна Вернона Предметно Ориентированное Проектирование и к подходу разработки который называется DDD. Основной посыл:
— Мы пишем код, чтобы решать задачи бизнеса. А потому бизнес-логика и ее понимание, важнейшая часть наших систем. Domain Driven Design как раз об этом. Это подход как строить приложение в центре которого находится бизнес.

Осознав все это все стало на свои места, вот решения которые помогут в разработке:
— Расслоение системы. Каждрый уровень системы имеет свое предназначение. Уровень бизнес логики, уровень приложения, уровень представления, уровень инфраструктуры. Каждый уровень системы меняется с разной периодичностью, к каждому уровню требуется свой поход в тестировании.
— Модульность, модуль — блок, элемент сайта который можно использовать повторно, с помощью блоков можно быстро построит динамическую страницу сайта.
— База данных, шаблоны, внешний вид — это вторично, разработка должна вестись от бизнес модели, от бизнес логики. Работа с базой через репозитории, работа с внешним миром через адаптеры и порты. Гексогональная архитектура или минимум Onion Architecture.

Нужен был первый клиент, не просто клиент, а клиент со сложной бизнес логикой, желательно автозапчастей.

У нас появился клиент которому требовалось реализовать интернет-магазин автозапчастей. И у нас были специалисты имеющие огромный опыт в разработке программного обеспечения ориентированного на автозапчасти. Какая же это интересная и сложаня предметная область — кроссы, проценка, финансы, отчеты, работа со складом, работа с поставщиками, загрузка прайс-листов.