Вчера: "Domain-driven design" by Eric Evans

[singalen]

1. Мне подумалось: Не миф ли CMM Level.

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

С другой стороны, у Сергея был такой опыт: людям неудобно было вводить требования в систему [много-денег-RT], они попросили чего-то другого. Им разрешили вводить их в виде Word-овских документов, и тут-то всё и встало: они не знали, в какой форме, по какому шаблону вводить требования.

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

В технологии SSADM — той, которую я знаю лучше всего, — для каждой методики есть список документов, которые она создаёт, и для каждого документа подробно описаны:

• а) формат и содержание;
• б) критерии и методы проверки качества, как-то:
• чеклисты с проверочными вопросами;
• методы формальной проверки полноты и непротиворечивости. Например, специальная матрица проверяет, для каждого ли объекта БД есть задача, которая делает ему C,R,U,D.

Методиками в SSADM называются, к примеру, такие элементы технологии: "логическое моделирование данных", "моделирование информационных потоков", "управление требованиями".

2. "Domain-driven design" by Eric Evans

Я немного покритиковал Эванса, как оказалдось - потому что недочитал до второй половины.
Показалось, что много воды, что одна и та же мысль повторяется на разные лады. Не, мысль очень правильная:

• выделяйте модель предметной области (domain model);
• ведите общий словарь в терминах домена;
• говорите на языке этого словаря друг с другом и заказчиками, пишите код на нём; (два замечания: для заказчика эти слова всё равно будут значить не то, что для вас. Для него пациент - это человек, у которого взяли анализ, плюс личная карточка. А для нас - запись в БД и кусок памяти, определённым образом заполненный байтами).
• создавайте business layer в виде модели домена, и изолируйте его от прочих слоёв.

Но мне объяснили, что дальше идёт несколько очень интересных глав.

Сергей получил от этой книги индульгенцию на классы с именем "*Service". До тех пор он подозревал, что это слово не означает ничего, примерно как "Common", "General", "Object", "Data" или вот более дискуссоинный пример - "Manager". ("Manager" - это м.б. паттерн "utility class"). Ну а теперь мы знаем, что "сервис" бывает не только внутрисистемный, тот, что в словосочетании "Service layer", но и как понятие слоя бизнес-логики ("utility class").

Диме Бочоришвили книга ответила на некие ещё несформулированные вопросы и этим очень понравилась.
Далее о модели предметной области и паттернах, характерных только для модели домена, но не для реализации.
Эванс выделяет такие полезые паттерны для моделей анализа:

• Entity (объект, имеющий identity)
• Value object;
• Composite. Это не GoF-овский Aggregate, он "жёстче". На его элементы нельзя ссылаться извне, их нельзя "вынимать" и без корневого объекта они не бывают. Связь с чёрным даймондом у него внутри навигабельна в обе стороны;
• 1-directional association;
• и что-то ещё;

Меня эта идея натолкнула на мысль, что бывают паттерны модели предметной области ("модели-задачи"), а бывают паттерны модели-решения. Например, такой вот "strong composite" (термин мой) - это паттерн анализа, а Observer - паттерн реализации.
Эту мысль надо развить.
Пообещал себе прочесть фаулеровские "Analysis patterns".

Об отличиях постановки задачи от модели-"постановки задачи" от модели-решения и от собственно решения.

Как вы сами понимаете, даже если мы говорим с заказчиком на одном языке, слово "пациент" значит для нас разные вещи.
Так вот, задача заказчика не эквивалентна модели этой задачи.
Модель-постановка задачи не эквивалентна модели решения; а та не эквивалентна самому решению — программе на языке, скажем, Java.
Потому что:
1) Ассоциация между классами на диаграмме UML, даже именованная, несет не такую семантическую нагрузку, как связь между накладной и товаром, или ссылка между классами в коде на Java. По ней не видно:

• навигабельна ли она в обе стороны или в одну;
• реализована ли она как ссылочное поле или как реестр;
• какие классы могут делать по ней навигацию - только владелец, все, или какоей-то подмножество;
• и ещё много чего по ней не видно, как из области задачи (бизнес-процесса), так и из решения (java-кода).

2) Кто-то в словах "ввод данных о пациенте" слышит "MVC, где модель — объект-пациент", кто-то "Grid с RecordSet-ом из таблицы пациентов", а кто-то вообще "Монада GUI, параметризованная типом данных пациента".

3) Ну и в SSADM выделяются "модель существующей системы" и "модель проектируемой системы". В терминах этой статьи, они равны понятиям "модель задачи" и "модель решения" соотв.
4) И чтобы модель точно соответствовала предметной области, вместо конструкторов и оператора new для пациента пришлось бы заводить объект-папу и объект-маму. Что есть нонсенс.

Из приколов:
(речь об отображении требований на языки со статической и динамической типизацией): "Сегодня я пассажир, а завтра пациент".

Comments

[nponeccop.livejournal.com]

Наличие "тренеров по процессу" подразумевает обучение разработчиков жить по другому и мыслить другими категориями, а не просто тупо соблюдать кем-то написанные правила?

Да, о какого размера (в людях) конторах или конторе идет речь?

[cossac.livejournal.com]

да, тренер должен объяснить не просто что делать, но и показать как это делать и почему это приводит к результату.

50-100, в бОльших работать не довелось