нашел вот такую штуку: http://habrahabr.ru/blogs/webdev/70424/ посмотрю (английский текст занимает много времени.. хотя на русском я не нашел трудов, но пока ограничусь хабром).

нашел вот такую штуку: http://habrahabr.ru/blogs/webdev/70424/ посмотрю (английский текст занимает много времени.. хотя на русском я не нашел трудов, но пока ограничусь хабром).

Любопытный материал. Хотя там в основном обсуждается как описать технологический процесс разработки, какими разными диаграммами, и как этот процесс планировать.
К сожалению декомпозиция системы на относительно независимые элементы (предметы - subject areas)  в этом материале не упоминается (в отличие от материала в Википедии). Представление же системы стандартным набором диаграмм UML вряд ли можно рассматривать в качестве "изюминки" FDD.  А технология разработки/проектирования не дает ответа на сколько и каких подсистем или предметов декомпозировать систему.
В каждом конкретном случае декомпозиция получается исходя из специфики бизнеса и системно-технических решений/платформ. В Вашем случае можно посмотреть на уже работающую систему, как она де-факто декомпозируется по предметной области - возможно, по специализации работающих с ней пользователей или рынкам: например, операции на вторичном рынке и первичное размещению ценных бумаг - достаточно разные виды деятельности, возможно в Вашей системе интерфейсные формы и объекты базы данных могут быть отнесены к относительно изолированным ВИ/компоненты/подсистемы по этим видам деятельности (или как-то иначе).

Я посмотрел, там, видимо наиболее любопытен рисунок: http://upload.wikimedia.org/wikipedia/commons/9/99/Fdd_process_diagram.png

Попытался его перевести, может ли кто посмотреть в плане наиболее критичных ошибок?..

Описание (опять же я мог чего и не понять из английского текста):

Разработка общей модели
Проект начинается с многоуровневого определения границ системы и её контекста (как я понимаю, доменной модели). Далее,  детализированная модель создается для каждой области моделирования. Для удобства поддержки, они делятся на маленькие группы, объединяющиеся по областям. Эти доменные модели областей, в итоге, объединятся в общую модель системы.

Составление списка требуемых свойств системы
Знания при создании модели используются для построения списка фич (свойств системы). Это сделано при помощи функциональной декомпозиции домена по предметным областям. Они содержать бизнес-активности, а так же описание, какая из бизнес-активностей формирует какой список фич. Фичи являются малыми составляющими клиентский функций, например: "посчитать количество продаж". Фичи должны быть реализованы не более чем за 2 недели, иначе их следует делить на меньшие части.

Планирование работы над каждым свойством

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

Проектирование каждого свойства

Под дизайном здесь не понимается дизайн интерфейса. Уточняется диаграмма последовательности по группе фич, которые можно реализовать за 2 недели.

Конструирование каждого свойства

Разработка.

Лучшие практики
Тут мне была интересна только декомпозиция.

не очень мне тут понятно, когда у нас идет дизайн интерфейса... Мы же, по идее, должны протрассировать фичи на элементы интрефейса..

не очень мне тут понятно, когда у нас идет дизайн интерфейса... Мы же, по идее, должны протрассировать фичи на элементы интрефейса..

В тексте приводится определение "Фича - небольшая часть функции в форме <действие> <результат> <объект>, с результатом, имеющим ценность с точки зрения клиента. Например - "рассчитать суммарный объем продаж" или "проверить пароль пользователя".

В смысле этого определения фича может иметь вид "заполнить <название поля> интерфейсной формы значением <название показателя>".

Из текста раздела Buid feature list следует, что система декомпозируется по иерархии:
 автоматизируемая область (домен) -> предметные области (subject areas) -> виды деятельности (business activities) -> список фич.
Причем каждой фиче соответствует действие (по крайней мере) одного из видов деятельности (activity).

хм, теперь вроде картинка складывается
спасибо