Документируйте свой домен
Отрывок из книги Эшли Пикок "Создание программного обеспечения с использованием современных методов построения диаграмм".
В следующих главах мы рассмотрим жизненный цикл создания приложения с нуля. Мы не будем писать код приложения, но будем документировать важные шаги с помощью диаграмм. Я написал главы примерно в том порядке, в котором я буду описывать каждый шаг в своей профессиональной карьере, но вам может подойти немного другой порядок.
Для начала мы создадим модель предметной области. Моделирование предметной области — это основной способ определения важных аспектов бизнеса. Обычно она создается совместно инженерами, заинтересованными сторонами в продукте и бизнесе, чтобы убедиться, что все основные части бизнеса согласованы с тем, как выглядит модель предметной области.
Это делает его хорошим кандидатом для построения диаграмм. Если документировать модели предметной области с помощью диаграммы, эта модель предметной области воплотится в жизнь и с большей вероятностью будет применяться на практике. Кроме того, благодаря простоте Mermaid можно создать черновой вариант модели предметной области в режиме реального времени при обсуждении с коллегами на собрании.
Я рекомендую прочитать Domain-Driven Design: Решение проблем в основе программного обеспечения[Eva03], если вы хотите узнать больше о DDD.
Как только вы освоите моделирование предметной области, это сделает вашу жизнь намного проще. Будут моменты во время моделирования предметной области, когда все внезапно сойдется воедино, все будут на одной странице с точки зрения их понимания ландшафта, и все будут говорить на одном языке.
Самым мощным применением DDD, с которым я столкнулся, была работа в страховой компании. Перед командой, в которой я работал, была поставлена задача определить, как именно наши продукты продаются и кому — звучит просто, правда? К сожалению, данные были повсюду, и клиенты могли использовать множество путей для совершения покупки, причем на каждом пути были доступны разные данные. Никто из нас понятия не имел, как представить эти концепции в нашем коде, поэтому мы потратили несколько дней на моделирование предметной области. Мы опробовали разные идеи и подходы, и в конце концов пришли к кульминации нескольких разных идей и смогли легко воплотить модель предметной области в код.
Я считаю, что самая большая сила, которая исходит от моделирования предметной области, — это сотрудничество, то, как оно приводит всех в путешествие и, в конечном итоге, к одному и тому же месту назначения. Становится легко говорить о том, над чем мы работаем, поскольку мы все говорим на одном языке, и код легко течет, потому что у нас есть четкое представление о том, как мы должны представлять эти бизнес-требования, используя нашу модель предметной области. К концу проекта даже заинтересованные лица, не являющиеся техническими специалистами, использовали ту же терминологию, которую мы придумали при моделировании предметной области.
Последнее, что я хочу сказать о DDD, — это его способность позволить вашему домену и коду развиваться с течением времени. Поскольку мы документируем нашу модель предметной области, мы можем ссылаться на нее в любой момент. Очень часто новые требования появляются позже, и в этот момент мы можем вернуться к модели предметной области, посмотреть, соответствует ли она новым требованиям, а если нет, то ее можно развить и скорректировать по мере необходимости. Ядро предметной области, которую мы смоделировали в страховой компании, до сих пор не повреждено, но с тех пор оно эволюционировало, добавив новые объекты и варианты использования.
Один из доступных нам типов диаграмм в UML называется диаграммой классов. Его можно использовать для моделирования классов, но его также можно использовать для моделирования предметных областей, что имеет большой смысл, если учесть, что ваша модель предметной области реализована в вашей кодовой базе с помощью классов. Настоящая сила диаграммы проявляется, когда мы начинаем моделировать отношения между сущностями, что мы можем легко сделать с помощью диаграммы классов UML.
Определите важные объекты
Во-первых, при создании модели предметной области подумайте обо всех важных объектах вашего бизнеса. Для тех, кто не знаком с этим термином, сущность представляет собой ключевую концепцию в бизнесе. Обычно сущности — это фразы, которые чаще всего используются в кодовой базе и на собраниях. Книжный издатель, например, скорее всего, будет иметь такие объекты, как книга, глава и автор. Мы не будем вдаваться в подробности, но в вашей кодовой базе они будут содержать данные сущностей и бизнес-логику. Продолжая пример публикации, книга будет иметь название для данных и, возможно, некоторую бизнес-логику, которая подсчитывает количество слов.
Выдуманная компания, которую я буду использовать в этих главах, называется Streamy и пытается сделать себе имя в индустрии потокового видео.
Я бы сказал, что для компании, занимающейся потоковым видео, ее наиболее важной сущностью, вероятно, будет Title — представление реальных видео, которые Streamy предлагает своим клиентам.
Как только вы подумали о сущности, какие связанные сущности у вас могут быть?
Как правило, каждый Title будет принадлежать Genre, а каждый Genre будет иметь список связанных с ним Titles . Теперь мы определили две сущности и то, как эти две сущности связаны друг с другом, поэтому теперь мы можем начать формировать нашу модель предметной области.
Дизайн, ориентированный на домен
Наряду с моделированием предметной области существует проектирование, ориентированное на предметную область (DDD), которое представляет собой методологию не только для определения модели предметной области, но и для сохранения этой модели предметной области в кодовых базах, над которыми вы работаете, путем обеспечения того, чтобы сущности вашей модели предметной области были представлены в вашей модели. кодовая база.
Если вы не знакомы с какой-либо конструкцией, я настоятельно рекомендую прочитать о них после прочтения этой книги, но даже не зная DDD в деталях, вы можете попробовать создать модель предметной области позже в этой главе.
Задокументируйте наши первые отношения
Теперь, когда мы понимаем, что такое дизайн, ориентированный на предметную область, и для чего он используется, мы можем приступить к созданию модели предметной области для Streamy.
Мы собираемся использовать Mermaid для создания нашей модели предметной области, и добавить эти две сущности очень просто:
classDiagram
Title -- Genre
Вот и все — наши первые две сущности определены! Если мы создадим диаграмму, она будет выглядеть так:
В Mermaid разметка для любой диаграммы (за исключением настройки конфигурации, которую мы рассмотрим позже) — это тип диаграммы, которую вы хотите создать. В нашем случае это classDiagram, который информирует Mermaid о том, как форматировать и интерпретировать следующие строки.
При создании модели предметной области в UML каждая строка после начальной документирует отношения между двумя объектами. В случае Title и Genre,, где каждый объект будет содержать ссылку на другой, такой тип отношения известен как ассоциация. В «Русалке» именно здесь появляется вторая строчка:
Title -- Genre
Чтобы определить любую связь, мы записываем две сущности, разделенные набором символов, определяющих тип связи. Ассоциация определяется с помощью двух дефисов. Рассмотрим ассоциации подробнее.
Определить ассоциации
Ассоциация — это первый тип отношений, который мы рассмотрим, и это самый свободный тип отношений, доступный в диаграмме классов UML. Обычно, чтобы отношение можно было классифицировать как ассоциацию, сущности должны существовать независимо друг от друга и, вероятно, иметь свои собственные жизненные циклы. Кроме того, для ассоциаций, как правило, нет «владельца» отношения, они просто связаны. Таким образом, вы можете думать об их отношениях как об «использовании» друг друга, а не о том, что один владеет другим.
В нашем случае с Title и Genre у нас может быть страница в нашем приложении, которая просто показывает Genres без каких-либо Titles. Однако мы, вероятно, хотим иметь возможность перечислять Titles внутри Genre, а также отображать конкретные Title’s Genre, поэтому они должны иметь какую-то ссылку, поскольку все отношения должны быть задокументированы в модели предметной области.
Ассоциации — это очень свободные способы связать два объекта, но некоторые отношения образуют более тесную связь между двумя объектами. Давайте посмотрим на один следующий.
Определение составных отношений
Как только вы определили первые две сущности, подумайте о других сущностях, связанных с любой из них. Мы собираемся сосредоточиться на заголовке, так как это наш основной объект. Я могу думать о двух связанных объектах:
• Season
• Review
Однако эти две сущности не подходят для ассоциации. Подобно ассоциациям, мы должны думать о том, как каждая из них ведет себя по отношению к Title. Они не имеют смысла сами по себе, как ассоциации, и без Title они, вероятно, вообще не имеют смысла в нашей области. В конце концов, если мы удалим Title, ни один из них не сможет существовать. Например, у вас не может быть Season вместо несуществующего Title, и то же самое верно для Review.
Этот тип отношений называется композиция, и мы можем задокументировать его следующим образом в Mermaid, используя звездочку и два дефиса:
classDiagram
Title -- Genre
Title * -- Season
Title * -- Review
И если мы сгенерируем диаграмму, она будет выглядеть так:
Обратите внимание на разницу между разными классами. Title и Genre связаны сплошной линией без стрелок, тогда как Title и Season отмечены сплошным ромбом на линии, соединяющей их, что означает, что связь является композицией.
Сторона, на которой находится ромб, указывает на класс, содержащий ссылку, но вы можете думать об этом так же, как об отношениях родитель-потомок, где ромб означает родителя, поскольку дочерний элемент не может существовать без родителя. В отличие от ассоциаций, родитель является владельцем отношения.
Направление отношений
Хотя Mermaid позволяет записывать отношения в любом направлении (например,
‘*–‘и‘–*‘), я рекомендую всегда помещать родительский элемент слева для более удобного чтения и меньшей когнитивной нагрузки при определении направления отношения, как вы можете. просто читайте слева направо.
Чтобы завершить составные отношения, необходимые для нашей модели предметной области, Season бесполезна без своего аналога Episode. Подобно другим составным отношениям, Episode вероятно не имеет особого смысла, если не принадлежит Season. После добавления нашей окончательной составной связи наш код Mermaid выглядит так:
classDiagram
Title -- Genre
Title * -- Season
Title * -- Review
Season * -- Episode
Хотя макет полностью зависит от вас и ваших личных предпочтений, я предпочитаю группировать отношения каждой сущности вместе и разделять группы пустой строкой для удобства чтения.
У DDD есть мнение
Дизайн, ориентированный на предметную область, очень самоуверен, поэтому имейте в виду, что вы могли бы не моделировать мои примеры, как этот, если бы вы их создавали. Сама модель не является важной частью, по крайней мере, в контексте этой книги — важными являются синтаксис и сами диаграммы.
Теперь мы знаем два типа отношений:
• Ассоциации, которые представляют собой два слабо связанных объекта, которые могут существовать независимо друг от друга.
• Композиции, указывающие на то, что два объекта тесно связаны и не могут существовать независимо друг от друга.
Однако еще один находится между этими двумя с точки зрения того, насколько тесно связаны две сущности. Мы рассмотрим это в следующем разделе.
Определение агрегатных отношений
Наша модель предметной области начинает обретать форму, но в ней все еще отсутствуют несколько ключевых объектов. В конце концов, разве не всем нравится знать Actors, которые появляются в заголовке?
Но эта сущность не подходит для сложных отношений. Зная, что Actors определенно удобен, Title может существовать без Actors, и точно так же Actor может существовать независимо от Title (или принадлежать многим Titles, поэтому, если один будет удален, они, возможно, будут существовать в другом, поэтому останутся на месте. ).
Давайте обновим наш код Mermaid, добавив Actor:
classDiagram
Title -- Genre
Title * -- Season
Title * -- Review
Title o -- Actor
Season * -- Episode
Синтаксис для совокупныхотношений: o — (буква o, за которой следуют два дефиса), и после создания они отображаются следующим образом:
Совокупная связь также отображается в виде ромба, но вместо того, чтобы быть сплошным ромбом, она пуста. В совокупных отношениях все еще есть владелец — родитель. Однако связь между ними не так сильна, как составная связь, и если родитель будет удален, дочерний элемент все еще может существовать.
Как упоминалось в начале главы, выбор того, как моделировать предметную область, может сильно различаться между компаниями или коллегами. В другой модели предметной области, возможно, вы группируете Actors, например, в Cast. Это, возможно, изменит тип связи на составную, поскольку Cast, созданный для Title, вероятно, не останется, если Title будет удалено.
Теперь, когда мы знаем три основных типа отношений, которые мы можем использовать, давайте рассмотрим, когда использовать каждый из них.
Надеемся, вам понравился этот отрывок. Вы можете приобрести книгу прямо на The Pragmatic Bookshelf. Во время весенней распродажи вы можете сэкономить 50 % на электронной книге с кодом DATAFLOW2023 до полуночи по восточному времени 25 апреля 2023 г.
