Вторая составляющая, единый язык (ubiquitous language) – это система терминов и понятий, который у нас получается в результате проектирования DDD.
Не должно быть так, чтобы мы какую-то модель построили, потом выкинули её и начинаем говорить, как попало, с какими-то новыми терминами, что-то объясняя на пальцах. Нет, у нас модель предметной области, именно в её терминах, её отношениях, в её поведении мы должны разговаривать, обсуждать структуру технических заданий и прочее. Язык строится на модели предметной области, он должен чётко из неё следовать. И он же проверяет модель предметной области. Если модель предметной области, которую вы построили – очень-очень сложная и вам сложно это использовать в языке, вам постоянно хочется использовать другие термины и другие предложения – это значит, что у вас неправильно построена модель. Хороший способ проверить, хорошая у вас модель или нет – попробовать использовать её термины на русском языке.
Построенная модель используется во всех документах. Т.е. мы не просто так строим какие-то модели, разговариваем, и всё, дальше разработчики начинают городить микросервисы, контроллеры, IoC-контейнеры, фасады и прочее.
Нет, именно на основании этих моделей должны строиться официальные документы, включающие ТЗ, требования, архитектуру системы и т.п., И как ни странно, именно этот же язык должен использоваться в КОДЕ.
Т.е. если мы при разговоре с людьми использовали эту модель в русском языке, то при разговоре с компьютером мы должны использовать эту же модель. У нас есть модель предметной области, и она порождает терминологию. Так как она состоит из понятий, сущностей и поведений.
Это значит, что слово языка даёт возможность нам использовать эту модель, язык, порождаемый ей для общения между собой. А тот факт, что термины у нас имеют чётко ограниченные значения – даёт нам возможность использовать эти термины в коде.
Третье — проектирование по модели.
Наиболее сложная часть DDD. Сложная она по техническим причинам в силу несовершенного инструментария для всего, инерции мышления и многих других причин. Вот что такое проектирование по модели (по Эрику Эвансу):
"Проектирование по модели (Model Driven Development) – проектирование архитектуры, при котором соблюдаются максимально точное соответствие между некоторым подмножеством элементов программы и элементами модели. Если у нас была модель предметной области – и мы начинаем строить для неё программу - получаем некоторое предсказуемое овеществление в код.
Кстати, правила соответствия сейчас закреплены у нас в документах по "рельсам архитектуры" и доступа к БД, и есть планы их контролировать.
Антипример
Очень часто сейчас у нас получается так – где-то в глубине системы, по её объёму, у нас происходит бизнес-логика – нам так говорят разработчики, мы в это ВЕРИМ, оно так проявляется. Но фактически мы видим, что используются совершенно другие понятия – здесь у нас какие-то датасеты, датаридеры, команды, коннекторы, и прочие вещи, которые в модели предметной области даже и не упоминались. Я уже не говорю, что если вы попробуете разговаривать на этом языке с людьми из предметной области, с людьми для которых вы пишете эту программу, то очень долго придётся объяснять, что вы имеете ввиду. Вот здесь мы видим, что у нас модель аналитики одна, а программа другая. Модель программы оперирует одними понятиями (датасет, коннекшн и т.д.), а модель предметной области – книги, авторы, издатель, читатель и т.д.
Т.е из-за выбранного способа реализации нужно нашу модель предметной области взять и ВЫКИНУТЬ, да? Она, конечно, полезной была, люди, которые её строили, лучше знали предметную область, но таким темпом она очень быстро потеряет свою актуальность. Но ведь модель предметной области имеет гораздо более широкое применение, чем техническая. Аналитики (правильные аналитики) общаются, прежде всего, в ней, она есть самый полный и компактный источник знаний.
Поэтому методика реализации, которая требует её выкинуть, сразу вызывает обоснованные подозрения, и поделом. А та, которая наоборот, считает её ценной — вызывает доверие.
Не должно быть так, чтобы мы какую-то модель построили, потом выкинули её и начинаем говорить, как попало, с какими-то новыми терминами, что-то объясняя на пальцах. Нет, у нас модель предметной области, именно в её терминах, её отношениях, в её поведении мы должны разговаривать, обсуждать структуру технических заданий и прочее. Язык строится на модели предметной области, он должен чётко из неё следовать. И он же проверяет модель предметной области. Если модель предметной области, которую вы построили – очень-очень сложная и вам сложно это использовать в языке, вам постоянно хочется использовать другие термины и другие предложения – это значит, что у вас неправильно построена модель. Хороший способ проверить, хорошая у вас модель или нет – попробовать использовать её термины на русском языке.
Построенная модель используется во всех документах. Т.е. мы не просто так строим какие-то модели, разговариваем, и всё, дальше разработчики начинают городить микросервисы, контроллеры, IoC-контейнеры, фасады и прочее.
Нет, именно на основании этих моделей должны строиться официальные документы, включающие ТЗ, требования, архитектуру системы и т.п., И как ни странно, именно этот же язык должен использоваться в КОДЕ.
Т.е. если мы при разговоре с людьми использовали эту модель в русском языке, то при разговоре с компьютером мы должны использовать эту же модель. У нас есть модель предметной области, и она порождает терминологию. Так как она состоит из понятий, сущностей и поведений.
Это значит, что слово языка даёт возможность нам использовать эту модель, язык, порождаемый ей для общения между собой. А тот факт, что термины у нас имеют чётко ограниченные значения – даёт нам возможность использовать эти термины в коде.
Третье — проектирование по модели.
Наиболее сложная часть DDD. Сложная она по техническим причинам в силу несовершенного инструментария для всего, инерции мышления и многих других причин. Вот что такое проектирование по модели (по Эрику Эвансу):
"Проектирование по модели (Model Driven Development) – проектирование архитектуры, при котором соблюдаются максимально точное соответствие между некоторым подмножеством элементов программы и элементами модели. Если у нас была модель предметной области – и мы начинаем строить для неё программу - получаем некоторое предсказуемое овеществление в код.
Кстати, правила соответствия сейчас закреплены у нас в документах по "рельсам архитектуры" и доступа к БД, и есть планы их контролировать.
Антипример
Очень часто сейчас у нас получается так – где-то в глубине системы, по её объёму, у нас происходит бизнес-логика – нам так говорят разработчики, мы в это ВЕРИМ, оно так проявляется. Но фактически мы видим, что используются совершенно другие понятия – здесь у нас какие-то датасеты, датаридеры, команды, коннекторы, и прочие вещи, которые в модели предметной области даже и не упоминались. Я уже не говорю, что если вы попробуете разговаривать на этом языке с людьми из предметной области, с людьми для которых вы пишете эту программу, то очень долго придётся объяснять, что вы имеете ввиду. Вот здесь мы видим, что у нас модель аналитики одна, а программа другая. Модель программы оперирует одними понятиями (датасет, коннекшн и т.д.), а модель предметной области – книги, авторы, издатель, читатель и т.д.
Т.е из-за выбранного способа реализации нужно нашу модель предметной области взять и ВЫКИНУТЬ, да? Она, конечно, полезной была, люди, которые её строили, лучше знали предметную область, но таким темпом она очень быстро потеряет свою актуальность. Но ведь модель предметной области имеет гораздо более широкое применение, чем техническая. Аналитики (правильные аналитики) общаются, прежде всего, в ней, она есть самый полный и компактный источник знаний.
Поэтому методика реализации, которая требует её выкинуть, сразу вызывает обоснованные подозрения, и поделом. А та, которая наоборот, считает её ценной — вызывает доверие.