В синей книге, глава 15 «Дистилляция», Эри c Эванс говорит о паттерне, который он называет Сплоченными механизмами. В этой главе много раз сказано, что возможности фреймворка должны быть раскрыты с помощью интерфейса выявления намерений (глава 10). Например, я цитирую DDD Ссылка :
Разделение концептуально связного механизма в отдельную облегченную структуру. Особенно следите за формализмом или хорошо документированными категориями алгоритмов. Раскройте возможности фреймворка с помощью интуитивно-понятного интерфейса. Теперь другие элементы домена могут сосредоточиться на выражении проблемы («что»), делегировании тонкостей решения («как») в рамках.
Пример, приведенный в книге, о подмножестве структуры обхода графа, реализованной в виде связного механизма, инкапсулирующего алгоритмы, необходимые для выполнения вычислений, которые запутывают область, что касается организационной схемы, а не теории графов. Эри c говорит, что инфраструктура представлена интерфейсом, раскрывающим намерения, но я запутался, если этот интерфейс использует язык предметной области, организационную схему или вместо этого представляет собой интерфейс, раскрывающий намерения, который говорит на языке графов. Теория.
У меня есть собственный пример программного обеспечения, над которым я работаю. Для этого необходимо создать набор документов с несколько разработанными правилами и валидациями, которые пользователи будут распечатывать. Реализация модели предметной области говорит о концепциях в этих документах и пытается express более понятными правилами, которых мы можем достичь (постоянное улучшение здесь). Каждый документ имеет идентификационный номер со значением домена, но до тех пор, пока пользователь работает над черновиком этих документов, номера можно переставлять и отбрасывать на основе некоторых правил, пока черновик не будет «принят» как действительный. Вычисления, необходимые для перестановки чисел, немного сложны и запутаны, затеняя модель, которая не касается самих чисел (даже если расчеты важны).
Я чувствую, что это хороший случай для применения шаблона Таким образом, мы можем тестировать «каркас» изолированно для проверки сложных вычислений, и в то же время мы освобождаем остальную часть модели от беспорядка, который они производят.
Итак, вопрос таков:
Когда в книге говорится о шаблоне и говорится, что он должен быть представлен с помощью интерфейса, раскрывающего намерения, говорит ли этот интерфейс на языке модели, Вычисления были взяты из (организационная структура; документы и правила), или они говорят на языке самого механизма (теория графов; числа и перестановки)?
Конечно, прагматизм не следует забывать, и мы опробую несколько вариантов, сохранив тот, который выглядит чище и хорошо выполняет свою работу; однако, когда я читал главу в поисках вдохновения, меня беспокоил вопрос, и я не мог ответить на него из текста (или я не смотрю в нужном месте).