Горизонтальные и вертикальные слои приложения

«У лука есть слои, и у людоедов есть слои! Ты понял?» - Шрек

Эта заметка навеяна выступлением Jimmy Bogard на 0redev под названием “Solid Architecture in Slices not Layers”, которую я всячески рекомендую.

Как и у людоеда, у любого современного приложения есть слои. Классической моделью является мордочка наверху, бизнес-логика по центру и базейка снизу. Такое разделение вполне уместно и определяется множеством причин.

Conway’s Law

Любой сложный проект требует вовлечения людей с разной специализацией и интересами. Кто-то пилит базы данных, кто-то лабает UI, а кто-то отвечает за логику. Такое разделение позволяет людям специализировать, а менеджеру масштабировать разработку: выделяя группы и подгруппы, отвечающие за отдельные куски.

Такой разделение еще сильнее выстраивает барьеры между слоями приложения, поскольку тут начинает во всей красе проявляться Conway’s Law, когда архитектура приложения начинает повторять структуру организации.

Памятка ынтырпрайз кодера

После прочтения “Release It!” захотелось сохранить ряд мыслей по поводу разработки распределенного ынтырпрайз софта. То, о чем нужно думать, что нужно подпилить, о чем нужно не забыть и т.п.

1. Все что может отвалиться, обязательно отвалится

База ляжет, удаленный веб-сервис начнет тупить, перестанет проходить автортизация, ажура начнет отбивать запросы (throttling). Это значит, что любое взаимодействие с внешними системами должно это учитывать. К сожалению, это легче сказать, чем сделать, поскольку современные библиотеки для распределенного взаимодействия слоены до нельзя и с точки зрения API не вполне очевидно, что именно может пойти не так, какие исключения могут вылететь, и что с ними нужно будет делать.