Я уже писал о том, что такое DSL и Software Factories, как выражается второе через первое и т.д.

Теперь вы можете увидеть это своими глазами на примере Services Software Factory V3.
Причем, именно увидеть: здесь разработчики выложили видео (рекомендую скачать, всего 11 мегабайт, но виднее) о том, как будет работать следующая версия их фабрики.

Отличия в частности в том, что в данном случае мы будем иметь "классический" DSL вместо обычного для фабрик набора указаний "сделай то-то".

Лично мне этот вариант кажется более логичным, гибким и удобным.

А вообще посмотреть стоит даже не столько ради самой фабрики, сколько ради того, как следует применять DSL. Просматривая ролик, подумайте о том, что если бы в ваших приложениях и фреймворках, которые вы поддерживаете и на базе которых делаете продукт, применялась такая техника - сколько времени вы бы каждый раз экономили? :)

В последнее время Microsoft "продвигает" концепцию Software Factories (я не знаю, как это адекватно перевести на русский язык, поэтому оставим так) и DLS (Domain Specific Languages).
Что же это за концепция и как ее можно использовать "во благо"?

Начнем с DSL.
Как следует из названия, это язык, описывающий некую модель. Давайте подумаем: а из чего состоит программа, которую мы пишем и в последствии поддерживаем?
Обычно есть какое-то ядро, какие-то расширения, слой работы с базой данных, пользовательский интерфейс...
А из чего, в свою очередь состоят они? Ведь это получается своего рода кубики: у нас обычно есть модули, контроллеры, объекты-транзакции, обладающие рядом специфичных для приложения свойств бизнес-объекты, провайдеры данных, сервисы и т.д. и т.п. Много у нас всего есть обычно. И все это специфично для нашей инфраструктуры, для нашего приложения. Все это нужно знать, помнить, документировать для потомков...
Создавая новый модуль мы создаем его в соответствие с некими правилами приложения, потом собираем из кубиков его функциональность.. Кубики мы тоже создаем, каждый такой кубик тоже создается в соотвествие с правилами, в результате чего части приложения "понимают" друг друга и работают.

Фактически, создавая правила вроде "любой бизнес-объект реализует IEntity" мы создаем свой собственный, специфичный для нашего приложения язык. Это он и есть - Domain Specific Language, DSL. Без него не обходится ни одно крупное приложение - везде есть свои правила и свои кубики.

Майкрософт предлагает явно выразить эти правила в виде формального языка. Иными словами, предлагается создать для своего приложения некий новый "язык", который будет оперировать сущностями нашего приложения ("модуль", "контроллер", "провайдер", etc) и отношениями между ними.
Разработав для нашего приложения такой язык мы сможем как бы выйти на новый уровень абстракции и в разработке оперировать не в терминах "класс", "интерфейс", "событие", а сразу в терминах нашего приложения.
Открыть дизайнер и набросать UML-подобную диаграмму, где каждый элемент есть сущность нашего проекта.
Чувствуете, куда я клоню? Тогда хватит об этом, перейдем к следующей теме :)

Software Factories.
Весь последний номер Архитектурного Журнала, выпускаемого Майкрософт и который, непонятно почему, но периодически приносит мне почтальон (наверное, галку где-то ткнул), был посвящен Software Factories. Так что же это такое?
Итак, Software Factory - это инструмент, позволяющий "провести" разработчика по определенному пути.

Ну например, разработчик говорит: "хочу создать модуль для приложения". Он открывает Software Factory и тыкает по слову "модуль". Его спрашивают название модуля, еще какие-то параметры, после чего пользователь нажимает "ОК" и получает в своем солюшне (solution) проект-заготовку модуля со всеми необходимыми инициализаторами и т.д. Этот пустой модуль уже готов загрузиться, быть понятым приложением и работать.
А Software Factory дальше подсказывает, что следующим шагом можно добавить бизнес-объект в модуль, или сделать контрол для отображения объекта в пользовательском интерфейсе.. Попутно предлагая документацию по каждому шагу.
Разработчик жмет "хочу бизнес-объект!" - и получает форму с вопросами: "как назовем?", "data layer для него сделаем?", "А View этому контролу нужен?", "не желаете ли свойства указать?"..
Клик по "ОК" - и вот у нас создался бизнес-объект в том виде, в котором он должен быть в приложении, слой базы для него - в полном соответствии с требованиями системы, контрольчик (view) для его отображения, контроллер этого view..
Словом, вся рутина, которую пришлось бы писать руками, наследуя классы, связывая их между собой и т.д. делается автоматически. Конечно, посредством DSL, а зачем я еще столько буков про него написал.

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

К чему я это все?
К тому, что в следующем постинге я расскажу о (еще одной) недавно вышедшей Software Factory - Web Client Software Factory, которая, на мой взгляд, очень заслуживает внимания.

Как говорится, оставайтесь на линии ;)