Архитектура по Фаулеру

Пару дней назад наткнулся на статью Фаулера "Кому нужен архитектор?" ("Who Needs an Architect?"). Ей уже сто лет в обед, но я ее первый раз вижу.

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

"Whether something is part of the architecture is entirely based on whether the developers think it is important. People who build “enterprise applications” tend to think that persistence is crucial. When they start to draw their architecture, they start with three layers. They will mention “and we use Oracle for our database and have our own persistence layer to map objects onto it.” But a medical imaging application might include Oracle without it being considered part of the architecture. That is because most of the complication is in analyzing the images, not in storing them. Fetching and storing images is done by one little part of the application and most of the developers ignore it."

А вот еще кусочек:

"There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication."

Это волшебно. Рекомендую почитать.

Если понравится, можно почитать еще пару интересных статей на тему архитектуры и проектирования:

Gaperton on Software Architecture - статья Gaperton о похожем с примерами и заодно с пояснениями, как согласуется архитектура с дизайном
The Difference between Marketecture and Tarchitecture - статья о компонентах архитектуры: Market-oriented и Technical-oriented
Is Design Dead? - статья об эволюционном проектировании, много разговоров на тему того, что ХР - это супер-пупер, но в целом есть что полезного почерпнуть

Что думаете?

PS. Поделитесь чем-нибудь интересным на эту тему.

Список интересных подкастов: выпуск #2

Где-то 3 месяца назад я написал первый выпуск списка интересных подкастов. Время идет, новые подкасты появляются и прослушиваются. Подошло время второго выпуска, надеюсь, вам понравится:

• .NET Rocks #442: Dino Esposito Gets Architectural!

В гостях у Карла и Ричарда человек, который не нуждается в особом представлении: Дино Эспозито. Дино рассказывает о том, чем занимается в данный момент времени, об архитектуре веб-приложений (и не только), сравнивает ASP.NET и ASP.NET MVC, а также немного проходится по другим веб-технологиям и библиотекам: AJAX, jQuery, Silverlight. Хороший подкаст для тех, кто хочет немного расширить свой кругозор и, возможно, узнать что-то новенькое.

• .NET Rocks #236: Eric Evans on Domain Driven Design

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

• Hanselminutes #169: The Art of Unit Testing with Roy Osherove

Гость Скотта, Рой Ошеров (Roy Osherove), рассказывает о модульном и интеграционном тестировании, основных различиях между ними, принципах написания хороших тестов, отличиях между моками и стабами (я тоже уже как-то писал об этом здесь, но Рой делает это намного лучше и проще), а также их практической пользе. Даже если вы считаете, что вы умеете писать тесты, думаю, вам все равно будет полезно послушать этот подкаст. Мне очень понравилось.

• Hanselminutes #171: Return of Uncle Bob

Uncle Bob возвращается! В этот раз Скотт обсуждает с Бобом вопросы, не связанные с SOLID, и даже не касающиеся качественного кода или дизайна. Речь идет о профессионализме. Можно ли считать, что индустрия разработки ПО уже созрела и нас всех с вами можно считать профессионалами? Чего нам не хватает для этого? Что такое быть профессионалом в сфере разработки? А также немного о том, как, по мнению Боба, будет выглядеть программирование через 40 лет. Очень интересный подкаст.

• Hanselminutes #153: Tables Turned - Mo Interviews Scott Hanselman

Ну, и напоследок снова нетехнический подкаст. Жена Скотта, Мо, берет интервью у него. Если вы хотите узнать, как и чем живут люди, похожие на Скотта, какие у него и его семьи планы на жизнь, как он умудряется соблюдать баланс работы и семьи, не надоедает ли ему то, что он делает, то это стоит прослушивания. Меня приятно увидило, что у Скотта есть далекоидущие планы, не связанные ни с разработкой ПО, ни тем более с работой в Microsoft. Хотите узнать, какие? Тогда слушайте :)

Приятного прослушивания!

Domain Driven Design: введение

Пару месяцев назад мне в руки попала книжка по Domain Driven Design (DDD). Отдельную рецензию на нее я напишу позже, когда дочитаю до конца. А пока что хотелось бы поделиться мыслями, которые у меня возникли в процессе прочтения.

Для начала я бы сказал, что DDD переворачивает взгляд на архитектуру приложения. Слабее, чем это делает MVC, но все же. Как нас учили проектировать в университетах, какие были наши первые проекты в реальной жизни, как программируют в 80-90% случаев в программистких конторах? Очень просто и прямолинейно. Есть у нас требования, анализируем предметную область (domain), находим сущности, анилизируем их поведение, действия, создаем высокоуровневую архитектуру, выбираем технологии, если нужно, строим UML-диаграммы. А дальше проектируем базу данных и от нее уже пляшем: слой доступа к данных (data access layer), слой бизнес-логики (business logic layer), слой представления (presentation layer), сервисы, etc. Т.е. снизу вверх. Все создаваемые таблицы в базе данных, как правило, мапятся на объекты предметной области как один-к-одному (с небольшими исключениями). Далее создаются сущности приложения, которые, как правило, подчиняются структуре сущностей в базе данных для удобства дальнейшей работы (опять же, могут быть исключения). Даже если мы используем какой-нибудь ORM (тот же Entity Framework или NHibernate), но генерируем сущности по базе данных, то мы все равно выходим на т.н. Data Driven Design, когда структура данных диктует нашу объектную модель. Да, это работает для решения многих задач, но не всех.

Domain Driven Design - совершенно другой зверь. Как следует из названия, это просто еще один способ проектирования, который фокусируется прежде всего на предметной области, на объектах реального мира, их поведении и взаимодействии, то есть фокусируется на модели и бизнес-логике, а не на структуре данных. Результатом подобного смещения приоритетов становится то, что мы стараемся перевести объекты предметной области и их поведение сразу в сущности приложения, пытаясь передать в них не только свойства и атрибуты этих объектов, но и поведение. Например, сущность "автомобиль" в DDD будет обладать не только атрибутами марка, цвет, цена, скорость и др., но и, по-возможности, каким-то поведением, связями с другими объектами. При этом проблема сохраняемости этих объектов куда-либо (например, в базу данных) отходит на второй план. Мы об этом не думаем, таким образом достигая сразу нескольких целей:

1. Откладывание реализации слоя сохранения (persistence layer или data access layer) позволяет реализовать его тогда, когда доменная модель уже спроектирована и реализована, то есть когда она устаканилась. Сколько раз в начале разработки приложения вы добавляете или убираете колонки в таблицах или даже целые таблицы? Сколько при этом приходится переписывать кода слоя доступа к данным? Хорошо еще, если вы используете ORM.
2. Слой сохранения реализуется как всего лишь один из инфраструктурных инструментов, а не как жизненно важный слой приложения. Акцент смещается на модель, а не на базу данных (или что у вас там) и слой доступа к ней. Это дает намного более сильный уровень независимости ваших классов от слоя сохранения (т.н. persistence ignorance), который дает возможность быстро поменять базу данных или перейти с нее на XML или вообще какие-нибудь внешние сервисы. По сути, это снижение связанности (decoupling).
3. Persistence ignorance дает еще одну полезную возможность. За счет того, что ваш код может жить и без слоя сохранения, его можно намного проще протестировать. Более того, в начале разработки вообще можно забить как на слой сохранения, так и на слой представления и написать сначала модель (по сути, слой бизнес логики), которую покрыть модульными тестами. Причем тесты здесь выполняют уже не столько роль парашюта на будущее, сколько роль клиентского кода более верхнего или того же слоя, при помощи которого вы можете отточить API классов модели, а также быстро поправить дизайн классов при необходимости. Слой же сохранения в таком случае можно для начала просто закрыть мок-объектами. Если пойти дальше, то в случае необходимости можно написать даже слой представления над моделью, еще даже не начав писать слой сохранения.
4. Из предыдущего пункта вытекает то, что если вы апологет TDD, то DDD - это точно ваше. Более подходящий для TDD способ проектирования и разработки приложений сложно себе представить.

Кроме всего прочего, Domain Driven Design стимулирует проектировать Rich Domain Model, то есть сущности, которые обладают не только состоянием, но и поведением. В результате разработки посредством Data Driven Design, мы очень часто получаем приложение, разработанное с использованием т.н. анемичной модели (Anemic Domain Model), в которой наши "бизнес" объекты на самом деле являются всего лишь сущностями для передачи данных из базы данных клиенту (UI, сервисы) и назад, т.е. обладают состоянием, но не поведением. Причем получаем мы это не потому что по-другому в Data Driven Design нельзя, а просто потому что в голове у нас это все те же записи из базы данных, просто переведенные на уровень кода. И как записи в базе данных не обладают никаким поведением, так и наши сущности, полученные оттуда, тоже сложно научить этому постфактум. Можно долго спорить о том, хороша ли анемичная модель или нет - это глупо. Просто как и у любого другого инструмента или подхода, у этого также есть свои положительные и отрицательные стороны и своя сфера применения. В приложениях, ориентированных лишь на CRUD операции, анемичная модель работает отлично. В приложениях, где много бизнес логики - уже не так хорошо. Бизнес логику приходится выносить в отдельные классы, которые будут оперировать объектами, хотя очень часто она по сути своей она принадлежит объектам.

Однако это еще не все. DDD - это не просто какая-то очередная методология разработки или догма проектирования. Скорее, это просто набор принципов, шаблонов, на которые можно опираться при проектировании. DDD очень активно оперирует ООП, паттернами, принципами (SOLID и пр.). Это вектор, направляющий разработку в несколько иное русло и помогающий решать задачи по-другому.

А что вы используете при проектировании приложений?

Дополнительно почитать о DDD можно в умных книжках:

1. Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software
2. Jimmy Nilsson. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
3. Tim McCarthy. .NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer)

И в онлайне:

1. http://domaindrivendesign.org/
2. http://hinchcliffe.org/archive/2005/03/20/189.aspx
3. http://www.emxsoftware.com/Domain+Driven+Design/
4. http://www.infoq.com/articles/ddd-in-practice
5. http://www.udidahan.com/2007/03/06/better-domain-driven-design-implementation/

Архитектура StackOverflow.com

Сегодня по дороге на работу/с работы прослушал подкаст Hanseminutes #134 о том, как Jeff Atwood, Joel Spolsky и его команда создали сайт StackOverflow.com. Пара слов о сайте: это с одной стороны типичный Q&A сайт-сообщество, а с другой – немного другая песня. Джефф и Джоэль провели достаточно серьезный анализ похожих сайтов и вроде как постарались сделать максимально удобный и продвинутый ресурс, ориентированный на IT-специалистов. Не могу судить о том, успешен он или нет, но вроде бы за месяц у них уже много пользователей.

В этом подкасте не было бы ничего особенного, если бы не техническое обсуждение особенностей реализации сайта. Во-первых, сайт написан с использованием ASP.NET MVC, что уже примечательно для меня, т.к. я последнюю неделю занимался его изучением. И это несмотря на то, что ASP.NET MVC еще только недавно вышел в бете. То есть это один из первых достаточно популярных сайтов, которые используют эту технологию. Во-вторых, несмотря на то, что это сайт, предполагающий высокую нагрузку, они использовали Linq to SQL в качестве ORM. Также они сами признаются, что им пришлось напрячься, чтобы реализовать output-кеширование разных разделов страницы (некоторые куски страницы обновляются раз в минуту, некоторые – чаще). Еще у них были большие проблемы с локами и дедлоками в MS SQL сервере и они были вынуждены перейти на “read committed snapshot”-транзакции (как это сделать в Linq to SQL и Entity Framework, можно почитать здесь). И это еще не все. Они использовали GZIP-сжатие страниц, причем не только для уменьшения размера страницы, но и для уменьшения размера страницы в кеше. И им действительно удалось добиться быстрой работы сайта на серьезных нагрузках. Можете проверить сами.

Однако это была лишь присказка :) Сказка начинается теперь. Угадайте, какое у них железо, сколько у них серверов? 4? 8? Больше? ОДИН! Один сервер, на котором крутятся и web-приложение, и база данных. 8-ядерный процессор, 4 Гб ОЗУ, 64-битная архитектура (процессор, ОС, .NET Framework, MS SQL сервер). Ничего особенного. В ответ на это Скотт говорит что-то вроде «это же не best practice, как вообще можно так делать?». И ему отвечают: «ну, мы перейдем со временем на ДВА сервера... когда будет нужно :)». И в конце добавляют контрольный выстрел в голову: их build-сервер, построенный на CC.NET, работает на ТОМ же production-сервере. Это какой-то ужас с точки зрения развертывания приложений, но это работает! :)

Со всем этим они умудряются делать ежедневные релизы новой версии, прогоняя ее на unit-тестах при каждом билде (обычный CI). Это значит, что у них получается нормальная стабильная версия, готовая к выходу в люди, каждый день. Думаю, нам всем есть чему поучиться в плане написания качественного софта, не говоря уже про performance на таком железе :) Да, нагрузка у них пока еще не слишком большая, но все же уже не детская. Я знаю продукты, на которых сайт лежал уже на десятке пользователей :)

А вы говорите, различные facebook’и работают на десятках, а то и сотнях серверов? Ну-ну :)

PS. Да, там уже доступна вторая серия этого общения. Еще не успел послушать, но если будет что-то интересное, сделаю update.

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

Upd2. Если кому-то интересно подробнее почитать про то, как рождался сайт StackOverflow.com, кому пришла в голову идея, сколько людей и как долго его писали, какие есть идеи его монетизации и сколько стоит обслуживание сайта в месяц - Джоэль рассказывает об этом в своей статье "How Hard Could It Be?: The Unproven Path"