Помня о главной цели — реализации бизнес-сценариев, — спустимся с небес на землю и обратим внимание на реальные корпоративные проекты. В этой статье мы узнаем, какие методы помогут нам правильно описать бизнес в архитектуре приложения.
Структура бизнеса и группы разработчиков
Программные проекты обычно разрабатывает команда инженеров, разработчиков ПО или архитекторов. Для простоты мы будем называть их программистами. Не ошибусь, если скажу, что всем им — разработчикам ПО, архитекторам, тестировщикам и другим инженерам — время от времени приходится программировать.
Почти всегда над программным проектом одновременно работают несколько человек. Поэтому требуется учесть еще пару моментов, главным образом коммуникационные и организационные издержки. Если же рассмотреть структуру организации, состоящей из нескольких команд, работающих над несколькими проектами или даже — временно — над одним проектом, то мы столкнемся с еще бо'льшими проблемами.
Закон Конвея гласит: «Организации, проектирующие системы <... > вынужДены создавать проекты, которые являются копиями коммуникационных структур этих организаций».
Другими словами, способ организации команд и коммуникации между ними неизбежно отражается на структуре ПО. При разработке программных проектов следует учитывать организационную схему, в соответствии с которой работают программисты, и их эффективные коммуникационные структуры.
Даже в одном проекте, выполняемом небольшой командой программистов, скорее всего, будет создаваться несколько функций или исправляться несколько ошибок одновременно. Это обстоятельство влияет на то, как мы планируем итерации, строим и интегрируем исходный код, а также создаем и развертываем готовое программное обеспечение.
Содержимое программных проектов
Проект корпоративного программного обеспечения включает в себя несколько рабочих продуктов, необходимых для создания и распространения приложений. Рассмотрим их подробнее.
Исходный код приложения
Все корпоративные приложения, как и любые другие, записываются в виде исходного кода. Исходный код, вероятно, является самой важной частью программного проекта. В нем содержится само приложение и определяются все его функциональные возможности. Он может рассматриваться как единственный источник достоверных данных, определяющих поведение программного обеспечения.
Весь исходный код проекта можно разделить на производственный код для работы готового продукта и тестовый код, необходимый для того, чтобы проверить поведение приложения. Тестовому и производственному коду соответствуют различные технологии, к их качеству предъявляются разные требования. В последствие можно говорить о производственном коде, который поставляется клиентам и обрабатывает бизнес-логику.
Программные структуры
Исходный код программного проекта упорядочен в виде определенных структур. В Java-проектах есть возможность объединять компоненты и задачи в Java-пакеты и модули проекта (рис. 1).
Рис. 1 Структура проекта
Структурирование этих компонентов — не столько техническая, сколько архитектурная необходимость. С технической точки зрения код, разбитый на пакеты произвольно, тоже будет работать. Однако структура помогает инженерам лучше понять программное обеспечение и реализуемые им задачи. Объединяя в группы программные компоненты, выполняющие согласованные функции, мы увеличиваем согласованность и улучшаем структурирование исходного кода.
В этой статье мы обсудим преимущества проблемно-ориентированного проектирования, описанного в книге Эрика Эванса (Eric Evans), и узнаем, почему и как следует разбивать код на пакеты в соответствии с бизнес-логикой.
Пока просто запомним, что мы группируем согласованные компоненты, так что логические функции будут объединяться в логические пакеты или модули проекта.
Java SE 9 поставляется с возможностью установки модулей в формате Java 9. Эти модули похожи на JAR-файлы с возможностью декларации зависимостей и использования ограничений других модулей. Поскольку мой блог посвящен Java EE 8, а модули Java 9 еще не получили широкого распространения в реальных проектах, рассмотрим только пакеты Java и модули проекта.
Следующим элементом в структуре программных проектов является более мелкая единица программных компонентов — класс Java. Классы и их функции заключают в себе определенный функционал. В идеале они слабо связаны между собой и отличаются высокой целостностью.
Есть много литературы о практиках чистого кода и представлении функциональности в исходном коде. Например, Книга "Чистый код" «Чистый код»1 (Clean Code) Роберта К. Мартина (Robert C. Martin) описаны такие методы, как правильное именование и рефакторинг, которые позволяют получить добротный исходный код в виде пакетов, классов и методов.
Системы контроля версий
Поскольку большинство программных проектов требуют координации при изменении кода, выполняемом одновременно несколькими программистами, исходный код хранится в системе контроля версий. Системы контроля версий (version control systems, VCS) зарекомендовали себя как обязательные средства, необходимые для надежной координации и отслеживания изменений в программных системах. Они же помогают понять, в чем заключаются эти изменения.
Существует множество вариантов систем контроля версий, таких как Git, Subversion, Mercurial и CVS. За последние годы распределенные системы контроля версий, в частности Git, были широко признаны самыми современными инструментами. Для хранения и разрешения конфликтов между отдельными версиями в них используется так называемое хеш-дерево, или дерево Меркля (Merkle tree), что обеспечивает эффективные различия и слияния.
Распределенная VCS позволяет разработчикам работать с репозиториями проекта в распределенной среде, не требуя постоянного подключения к сети. Каждая рабочая станция имеет собственный репозиторий, который включает в себя полную историю изменений и периодически синхронизируется с центральным репозиторием проекта.
На момент написания этой статьи в подавляющем большинстве программных проектов для контроля версий применяли систему Git.
Исполняемый код
В VCS-репозитории проекта хранится только исходный код, который создается и поддерживается разработчиками. Разумеется, корпоративные приложения развертываются в виде своего рода двоичных артефактов. Только эти готовые двоичные файлы могут выполняться в виде исполняемого программного кода. Именно двоичные файлы в конечном счете и являются результатом процесса разработки и компиляции приложения.
В мире Java это означает, что исходный код Java компилируется в переносимый байт-код и обычно упаковывается в виде архива веб-приложений (Web Application Archive, WAR, или Java Archive, JAR, соответственно). WAR- и JAR- файлы содержат все классы и файлы, структурные зависимости и библиотеки, необходимые для установки приложения. В итоге виртуальная машина Java (Java Virtual Machine, JVM) выполняет байт-код, а вместе с этим и бизнес-функции.
В корпоративных проектах артефакты развертывания, представляющие собой WAR- или JAR-файлы, либо развертываются в контейнере приложений, либо предоставляют сам контейнер. Контейнер приложений необходим, поскольку, помимо реализации собственно бизнес-логики, корпоративные приложения решают дополнительные задачи, такие как поддержка жизненного цикла приложения или обеспечение всевозможных форм коммуникации. Например, вебприложение, которое реализует определенную логику, но не передает данные по HTTP, вряд ли будет полезным. В Java Enterprise за такую интеграцию отвечает контейнер приложения. Упакованное приложение содержит только бизнес-логику и развертывается на сервере, который заботится обо всем остальном.
За последние годы появилось много Linux-технологий, таких как Docker, что способствует распространению идеи готовых двоичных файлов. Такие двоичные файлы содержат не только упакованные Java-приложения, но и все компоненты для его запуска: сервер приложений, виртуальную машину Java и необходимые двоичные файлы операционной системы.
Двоичные файлы создаются в процессе сборки программного обеспечения, что позволяет надежно воссоздать все двоичные файлы из исходного кода, хранящегося в репозитории. Поэтому двоичные файлы не должны храниться в системе контроля версий. То же самое касается и сгенерированного исходного кода. Раньше, например, классы JAX-WS, необходимые для SOAP-коммуникации, обычно генерировались из файлов дескрипторов. Генерируемый исходный код — созданный в процессе сборки, он не должен храниться в системе контроля версий. Хранить в репозитории следует только чистый исходный код, но не получаемые из него рабочие продукты.
Системы сборки
Процесс сборки в первую очередь обеспечивает компиляцию исходного кода программного проекта Java в байт-код. Это происходит каждый раз, когда в проект вносят изменения. Все современные системы сборки поставляют с удобными начальными установками, чтобы свести к минимуму дополнительную настройку.
В корпоративном мире с его многочисленными структурами и библиотеками важными этапами являются организация и определение всех зависимостей от API и реализаций. Системы сборки, такие как Apache Maven и Gradle, упростили разработчикам жизнь, предоставив им эффективные механизмы разрешения зависимостей. Система сборки записывает все зависимости (с соответствующими версиями), необходимые для компиляции и запуска приложения. Это упрощает настройку проекта для нескольких разработчиков, а также позволяет создавать повторяемые сборки.
Упаковка скомпилированных классов и их зависимостей в артефакты развертывания также является частью процесса сборки. В зависимости от используемой технологии артефакты упаковываются в WAR- или JAR-файлы.
Далее, в разделах «Gradle» и «Apache Maven», мы подробно обсудим реализацию и различия этих двух основных систем сборки.
Одно- и многомодульные проекты
Как уже говорилось, исходный код приложения можно объединять в Java-пакеты и модули проекта. Модули, построенные по принципу общей функциональности, представляют собой отдельно компилируемые подпроекты. Обычно они определяются системами сборки.
На первый взгляд, причины разделения проекта на модули вполне понятны. Объединение Java-кода и пакетов во взаимосвязанные модули позволяет создать более четкое представление для разработчиков, обеспечивает лучшую структуру и повышает согласованность.
Еще одна причина построения многомодульной структуры — это скорость сборки. Чем сложнее программный проект, тем дольше он будет компилироваться и упаковываться в артефакт. Разработчики, как правило, в каждый момент времени затрагивают лишь отдельные части проекта. Поэтому идея состоит в том, чтобы каждый раз перестраивать не весь проект, а только модули, необходимые для внесения желаемых изменений. Именно это преимущество предоставляет система сборки Gradle, обещая сэкономить время за счет того, что перестраиваются только те части, которые были изменены.
Еще одним аргументом в пользу этой практики является возможность повторного использования подмодулей в других проектах. Создавая подпроекты и выделяя их в самостоятельные артефакты, теоретически можно взять субартефакт из одного проекта и включить в другой. Например, обычным делом является создание модуля модели, который содержит все сущности, относящиеся к области бизнеса, обычно в виде автономных простых объектов Java (plain old Java objects, POJO). Такая модель упаковывается в JAR-файл и повторно задействуется как зависимость в других корпоративных проектах.
Однако у этой практики есть ряд недостатков, или, скорее, она внушает определенные иллюзии.
Иллюзии повторного использования
Напомню: программное обеспечение создает команда разработчиков, и структура проекта соответствует их коммуникационным структурам. Поэтому повторное применение модулей в рамках нескольких проектов требует некоторой координации.
Технические зависимости
Модуль проекта, предназначенный для повторного использования, должен соответствовать определенным критериям. Прежде всего технология общих модулей должна соответствовать новому проекту. Это кажется очевидным, поскольку влияет на детали реализации. Особенно сильно связаны с подключенными модулями и зависят от конкретной технологии применяемые библиотеки и структуры. Например, классы моделей в Java EE обычно содержат аннотации от API, такие как JPA, которые должны быть доступны во всех зависимых модулях.
Еще важнее с технической точки зрения зависимости от продуктов определенных версий сторонних производителей, необходимые для правильного функционирования совместно используемого модуля. Эти зависимости должны быть доступны при выполнении и не должны вызывать конфликтов с другими зависимостями или версиями. Коллизии с уже доступными на сервере зависимостями могут вызвать массу проблем. То же самое относится к деталям реализации, которые содержат неявные зависимости.
Типичным примером, иллюстрирующим сказанное, являются библиотеки отображения JSON, такие как Jackson и Gson. Многие сторонние зависимости задействуют определенные версии этих библиотек, которые могут вызывать конфликты с другими зависимостями или версиями при выполнении приложения. Другим примером являются реализации журналирования, такие как Logback и Log4j.
В целом совместно используемые модели должны быть как можно более самодостаточными или хотя бы содержать стабильные зависимости, которые не вызовут описанных проблем. Хорошим примером очень стабильной зависимости является Java EE API. Благодаря обратной совместимости с Enterprise Edition применение этого API и обеспечиваемая им функциональность не будут нарушены при появлении новой версии.
Но даже если Java EE API является единственной зависимостью общих модулей, это привязывает модель к определенной версии и уменьшает свободу внесения изменений.
Организационные проблемы
Совместно используемые технологии и зависимости вызывают ряд организационных проблем. Чем больше количество программистов и рабочих групп, тем сильнее влияние таких технологий и зависимостей. Группы должны согласовывать между собой применение определенных технологий, фреймворков, библиотек и их версий.
Если какая-то группа захочет что-то изменить в этой системе зависимостей или технологий, то такое изменение потребует значительной координации и накладных расходов.
Критерии повторного использования
Повторное использование — это всегда компромисс между простотой и возможным дублированием. Выбор в пользу того или другого определяется уровнем самодостаточности. Как правило, затраты на координацию зависимостей, версий и технологий перевешивают преимущества, полученные за счет избегания избыточности.
Однако остается важный вопрос: какие уровни образуют модули проектов по вертикали и горизонтали? Примером горизонтальной структуры является типичная трехуровневая архитектура кластеризации в виде представления, бизнес-логики и данных. Вертикальное разделение на уровни означает группировку функционала на основе бизнес-логики. Примерами могут быть модули учетных записей, заказов или статей, включающие в себя все технические требования, такие как конечные точки HTTP и доступ к базе данных. Теоретически оба типа модулей могут быть задействованы многократно.
Выше вероятность использования в других проектах горизонтальных многоуровневых модульных структур, таких как модели. Естественно, у модулей этого типа меньше зависимостей, в идеале их вообще нет. Вертикальные многоуровневые модульные структуры, наоборот, содержат детали реализации и ожидают определенных условий, таких как заданная конфигурация контейнера. Но это также зависит от технологии, используемой в рамках модулей, которые должны применяться многократно.
Артефакты проекта
Теперь немного отвлечемся и переключимся на артефакты развертывания нашего корпоративного приложения. Как правило, приложение создает один артефакт, который и будет запускать программное обеспечение. Даже многомодульный проект в итоге сводится к одному-двум артефактам. Таким образом, в большинстве случаев вся эта структура снова сводится к одному JAR- или WAR-файлу. С учетом того, что повторно использовать модули не всегда возможно, возникает вопрос: так ли нужна многомодульность в проекте? В конце концов, создание и управление подпроектами, вертикальными или горизонтальными, потребует от программистов определенных усилий.
Действительно, разделение кода способно ускорить сборку, если перестраиваются только те подпроекты, в которые вносились изменения. Однако в разделах «Apache Maven» и «Gradle» мы увидим, что сборка единого разумно построенного проекта в один артефакт выполняется довольно быстро и обычно есть другие причины, влияющие на скорость создания сборок.
Один проект — один артефакт
Целесообразно упаковать проект корпоративного продукта в один артефакт развертывания, создаваемый из единственного модуля проекта. Количество и структура артефактов развертывания соответствуют структуре программного проекта. Если в проекте появляются дополнительные артефакты, то они представлены в виде отдельных модулей. Это позволяет сформировать понятную и простую структуру проекта.
Обычно в корпоративном проекте создается переносимый JAR- или WAR-файл, генерируемый из одного модуля проекта. Однако иногда есть веские причины для разработки модулей, применяемых в нескольких проектах. Они, что вполне логично, оформляются в виде отдельных проектных модулей, создающих собственные артефакты, например в виде JAR-файлов.
Есть и другие причины для появления многомодульных проектов. Системные тесты, проверяющие внешнее поведение развернутого корпоративного приложения, не всегда зависят от кода готового продукта. В некоторых ситуациях имеет смысл представить эти тесты в виде отдельных модулей многомодульного проекта.
Другим примером являются клиентские технологии, которые попросту слабо связаны с серверной частью приложения. При использовании современных клиенториентированных фреймворков JavaScript связь с серверной частью также ослабевает. Рабочий процесс и жизненный цикл разработки клиентской части могут отличаться от таковых для серверной части приложения. Поэтому имеет смысл разделить технологию на несколько подпроектов или даже на несколько программных проектов. Подробнее мы обсудим эту тему в разделе «Структурирование для современных клиентских технологий».
Однако эти ситуации в более широком смысле также отвечают концепции соответствия артефактов модулям проекта. Проект тестирования системы используется и выполняется отдельно от кода готового продукта. Разработка и построение клиентской части тоже могут отличаться от разработки и построения серверной. Бывают и другие ситуации, когда такое разделение целесообразно.
Сборка систем в Java EE
Модули проекта описаны в виде модулей системы сборки. Независимо от того, сколько в системе проектов — один или несколько, например код продукта и системные тесты, — эти части строятся и выполняются как часть процесса сборки.
Хорошая система сборки должна иметь определенные функции. Ее основная задача состоит в том, чтобы скомпилировать исходные коды и упаковать двоичные файлы в виде артефактов. На этапе компиляции или упаковки также добавляются все необходимые зависимости. Есть несколько областей, где требуются такие зависимости, — например на этапе компиляции, тестирования или реализации. На каждом этапе нужны свои зависимости, включаемые в артефакт.
Сборка проекта должна быть надежной и воспроизводимой. Несколько сборок одного и того же исходного проекта с одинаковой конфигурацией должны давать одинаковые результаты. Это важно для реализации конвейеров непрерывной поставки (Continuous Delivery, CD), позволяющих создавать воспроизводимые сборки. При этом система сборки должна запускаться на сервере непрерывной интеграции (Continuous Integration, CI), таком как Jenkins или TeamCity. Для этого нужно, чтобы программное обеспечение управлялось через интерфейс командной строки, особенно в системах на основе Unix.
Система сборки, используемая инженерами-программистами, должна поддерживать те фреймворки и операционные системы, в которых они работают. Для систем сборки на основе JVM такая переносимость обычно предусмотрена. Иногда проекты имеют особые требования, такие как необходимость построения собственного кода для какого-то конкретного окружения. Однако в корпоративных приложениях Java это обычно не требуется.
В целом процесс сборки должен выполняться как можно быстрее. Загрузка и настройка системы сборки не должны быть продолжительными. Чем больше времени требует сборка, тем дольше придется ждать инженерам обратной связи в процессе разработки.
На момент написания статьи самой распространенной системой сборки была известная большинству Java-программистов Apache Maven.
Maven — это система сборки на базе Java, настраиваемая посредством XML. Проекты в ней определяются в рамках так называемой объектной модели проекта (project object model, POM). Maven основана на принципе программирования по соглашениям, что сводит к минимуму дополнительную настройку. Стандартная конфигурация хорошо подходит для Java-приложений.
Еще один распространенный инструмент сборки — Gradle. Он включает в себя основанный на Groovy предметно-ориентированный язык (Domain-Specific Language, DSL), предназначенный для настройки полностью расширяемых сборок проектов с поддержкой сценариев. Поскольку Groovy является полноценным языком программирования, сценарии сборки Gradle, естественно, являются эффективными и гибкими.
И Gradle, и Maven включают в себя расширенное управление зависимостями и хорошо подходят для сборки Java-проектов. Конечно, есть и другие системы сборки, такие как SBT, но Gradle и Maven являются наиболее распространенными и будут рассмотрены в следующих разделах.
Apache Maven
Система сборки Apache Maven широко используется в Java-проектах и известна подавляющему большинству разработчиков корпоративных программных продуктов. В основе системы Maven лежит принцип соглашения по конфигурации, который упрощает стандартные варианты ее применения. Однако конфигурация
Maven не всегда обеспечивает гибкость. Впрочем, негибкость иногда оказывается преимуществом. Поскольку очень сложно изменить стандартную структуру проекта Maven и процесс сборки, большинство корпоративных Java-проектов получаются очень похожими. Новые программисты легко осваивают настройку сборки проекта.
На рис. 2 показан типичный пример структуры проекта Maven.
Рис. 2. Структура проекта Maven
Эта структура знакома большинству разработчиков корпоративных Java-проектов. Здесь приведен пример веб-приложения, упакованного в виде WAR- файла.
Одним из недостатков Apache Maven является несколько непрозрачный способ определения нужных расширений сборки и их зависимостей. Применение стандартного соглашения без явного указания версий для расширений, таких как Maven Compiler Plugin, может вызвать нежелательные изменения используемых версий. Это нарушает принцип повторяемости сборки. Из-за этого в проектах, требующих воспроизводимости, часто явно указывают и переопределяют версии зависимостей расширений в POM. В этом случае проекты каждый раз собираются с использованием одних и тех же версий, даже если меняются версии расширений по умолчанию.
Еще один распространенный способ определения точных версий расширений — применение Super POM. Объектные модели проекта могут наследоваться от родительских проектов и тем самым сокращать шаблонные определения расширений. Программисты могут задействовать эффективные представления POM, отражающие результирующую объектную модель, с учетом стандартной конфигурации и возможного наследования.
Типичная проблема с POM в Maven заключается в том, что в корпоративных проектах очень часто злоупотребляют XML-определениями. В них преждевременно вводят расширения или настройки, которые и так содержатся в стандартной конфигурации.
В следующем фрагменте кода показаны минимальные требования POM для проекта Java EE 8:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example.cars</groupId>
<artifactId>car-manufacture</artifactId>
<version>1.0.1</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>8.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>car-manufacture</finalName>
</build>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<failOnMissingWebXml>false</failOnMissingWebXml>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
</project>Приложение для производства автомобилей car manufacture собрано в WAR- артефакт. FinalName переопределяет неявное имя WAR-файла, и получается файл car-manufacturing.war.
API Java EE 8 — единственная зависимость, необходимая в готовом коде простого корпоративного решения.
Тег properties устраняет необходимость явной настройки расширений сборки. Он используется для настройки параметров расширений Maven в каждой конфигурации. Указание этих параметров позволяет перенастроить расширение без явного объявления полных определений.
Указанные свойства позволяют построить проект с применением Java SE 8, причем считается, что все исходные файлы созданы в кодировке UTF-8. WAR-файлу не требуется передавать дескриптор развертывания web.xml, именно поэтому мы даем Maven указание не прерывать сборку при отсутствии дескриптора. Прежде для Servlet API требовались дескрипторы развертывания, чтобы настроить и сопоставить сервлеты приложения. После появления Servlet API версии 3 дескрипторы web.xml больше не нужны — сервлеты настраиваются с помощью аннотаций.
Процесс сборки в Maven состоит из нескольких этапов: компиляции, тестирования и упаковки. То, какие операции выполняются, зависит от выбранного этапа. Например, если выбрать этап упаковки, то будут скомпилированы исходные коды main и test, проведены контрольные тесты, после чего все классы и ресурсы будут упакованы в артефакт.
Команды сборки Maven запускаются через IDE или в виде командной строки mvn. Например, команда mvn package запускает этап упаковки, и на выходе создается упакованный артефакт. Подробнее об этапах и функциях системы Apache Maven вы можете узнать из ее официальной документации.
Gradle
На момент написания этой статьи система Gradle применялась в корпоративных Java-проектах реже, чем Apache Maven. Возможно, это связано с тем, что разработчики корпоративных приложений зачастую незнакомы с динамическими JVM-языками, такими как Groovy, который используется в Gradle в качестве языка сценариев сборки. Однако для того, чтобы создавать файлы сборки Gradle, глубокое знание Groovy не требуется.
У Gradle множество преимуществ, и в первую очередь гибкость. Для определения и возможной настройки сборки проекта к услугам разработчиков все возможности языка программирования.
У Gradle в фоновом режиме работает демон, который после первой сборки запускается повторно, чтобы ускорить последующие сборки. Он также отслеживает входы и выходы сборки, проверяя, были ли внесены изменения со времени последнего ее выполнения. Это позволяет системе кэшировать операции, сокращая время сборки.
Однако такая оптимизация может и не потребоваться. Это определяется сложностью проекта и используемыми зависимостями.
На рис. 3 показана структура сборки проекта в Gradle. Как видите, есть большое сходство с проектами Maven, с той разницей, что готовые двоичные файлы после сборки по умолчанию помещаются в каталог build.
Обычно проекты Gradle включают в себя сценарий оболочки для тех операционных сред, в которых не установлена система Gradle.
Рис. 3. Структура проекта Gradle
Следующий код представляет собой пример файла build.script
plugins {
id 'war'
}
repositories {
mavenCentral()
}
dependencies {
providedCompile 'javax:javaee-api:8.0'
}Задачи сборки в Gradle запускаются из командной строки с использованием команды gradle или посредством предоставляемых сценариев оболочки. Например, команда gradle build является аналогом mvn package и запускает компиляцию исходного кода, выполнение тестов и сборку артефакта.
Благодаря наличию полноценного языка программирования, определяющего файлы сборки, у Gradle есть ряд преимуществ. В случае обработки сценариев сборки в виде кода программистам удобнее применять принципы чистого кода, если определения становятся слишком сложными. Например, можно представить сложные операции сборки в виде нескольких методов с легко читаемым кодом.
Однако эти возможности порождают опасность чрезмерного технического усложнения сборки. Как уже отмечалось, негибкость Apache Maven иногда может быть преимуществом: возможность легко настраивать сценарии сборки позволяет создавать определения, присущие только данному проекту. Здесь, в отличие от Maven, перегруженные специфическими деталями сборки могут стать препятствием для программистов, незнакомых с проектом.
Опыт показывает, что подавляющее большинство сборок корпоративных проектов очень похожи. Поэтому возникает вопрос: так ли уж нужна гибкость Gradle? Для проектов, не предъявляющих особых требований к сборке, в отличие от, например, разработки продукта, вполне достаточно такой системы сборки, как Maven.
В дальнейшем, когда в качестве примера потребуется система сборки, мы будем использовать Maven. Однако все приводимые здесь примеры кода одинаково хорошо подходят и для Gradle.
Структурирование для современных клиентских технологий
После того как мы осветили современные системы сборки для корпоративных проектов, посмотрим, как интегрировать в серверную часть клиентские технологии.
Это делается довольно просто. Клиентская часть веб-приложений в большинстве случаев представляет собой создаваемые на сервере HTML-страницы со сценариями на JSP или JSF. HTML-страницы генерируются по мере необходимости, то есть по запросу клиента, и предоставляются ему. Для этого на сервере и располагаются^?- илиJSF-страницы. Все корпоративные приложения должны поставляться и развертываться как единый артефакт.
Введение в JavaScript-фреймворки
Благодаря новым технологиям разработки клиентской части, в основном сложным фреймворкам JavaScript и особенно одностраничным приложениям, эта ситуация сильно изменилась. Фреймворки для разработки веб-интерфейсов становятся все более клиентоориентированными и включают в себя гораздо больше бизнеслогики, чем прежде. На стороне сервера это означает, что взаимодействие между серверной и клиентской частью переходит от мелких методов к более крупным, описывающим бизнес-сценарии использования.
Таким образом, чем более клиентоориентированными и функциональными становятся фреймворки JavaScript, тем дальше взаимодействие между клиентской и серверной частью приложения уходит от тесно связанных запросов и ответов и приближается к стилю API, обычно в формате JSON через HTTP. Это также означает, что серверная сторона все меньше зависит от клиентской. Например, при передаче данных только через RESTful-подобные API в формате JSON собственные и мобильные клиенты, такие как смартфоны, могут применять тот же API, что и у клиентской части.
Мы наблюдаем эту тенденцию во многих корпоративных проектах. Тем не менее еще неизвестно, что лучше, переносить все больше логики на сторону клиента или создавать гибридные решения, часть которых реализована на стороне сервера, а часть — на стороне клиента. Не вдаваясь в детали, рассмотрим несколько ключевых моментов.
Подготовка данных и содержимого быстрее выполняется на стороне сервера. Там больше возможностей и ресурсов, чем на стороне клиента. На сервере также доступны такие функции, как кэширование, и есть возможность увидеть ситуацию в целом.
Сложные клиентские технологии часто включают в себя логику навигации, которая использует так называемые шебанг-страницы. Примером URL ше- банг-страницы является /car-manufacturing/#!/Cars/1234. Такие страницы, например car 1234, не размещаются на сервере, а генерируются на стороне клиента и существуют только там. URL-адрес такой подстраницы определяется после символа решетки и не учитывается при запросе ресурсов через HTTP. Это означает, что клиент запрашивает начальную входную страницу, которая затем реализует всю навигационную логику, включая генерацию подстраниц. Таким образом, с одной стороны, значительно уменьшается количество запросов, но с другой — сервер не обеспечивает подготовку и предварительную визуализацию содержимого — все происходит на стороне клиента. Именно по этой причине некоторые крупные компании, такие как Twitter, поначалу поддерживавшие такой подход, впоследствии отказались от него. В частности, просмотр этих страниц на мобильных устройствах сопряжен с определенными трудностями. Из-за ожидаемо медленных мобильных соединений и меньшей вычислительной мощности визуализация и выполнение сложной клиентской логики на этих устройствах занимают больше времени, чем отображение предварительно визуализированных HTML-страниц.
По сравнению с языками высокого уровня со статическим контролем типов, такими как Java, проблема клиентских интерфейсов на JavaScript заключается в том, что в языках с динамическим контролем типов выше вероятность пропустить ошибки программирования, которые иначе были бы обнаружены на стадии компиляции. По этой причине появляются более сложные клиентские технологии, такие как TypeScript, со статическими типами и языковые конструкции более высокого уровня, обработка которых передается обратно в JavaScript.
Структура современных клиентских приложений
Впрочем, независимо от того, какая именно технология выбрана для разработки клиентской части, сейчас клиентская часть корпоративных проектов гораздо сложнее, чем в прошлом. Это связано с новыми задачами организации ежедневного рабочего процесса. Обычно рабочие циклы клиентского интерфейса и серверной части немного различаются. При этом одни программисты занимаются преимущественно серверной частью, а другие — клиентской. Даже если вся команда состоит исключительно из разработчиков полного цикла, со временем происходит разделение обязанностей.
Поэтому в зависимости от используемой технологии имеет смысл выделить клиентскую часть в особый проект. Как уже отмечалось, если часть программного обеспечения поставляется отдельно или его жизненный цикл отличается от жизненного цикла остальной системы, имеет смысл создать для него особый модуль проекта.
Если клиентская часть может быть развернута независимо от серверной части, за исключением использования HTTP, то структура проекта довольно проста. Проект можно собрать и развертывать на веб-сервере отдельно и задействовать одну или несколько серверных частей со стороны клиента. Такой проект состоит только из статических ресурсов, например файлов HTML, JavaScript или CSS, которые передаются клиенту и выполняются на его стороне. Здесь нет жестких технических зависимостей от применяемых серверных технологий, за исключением HTTP API.
Этот момент, очевидно, должен быть тщательно оговорен во время разработки, а также описан в документации серверной части. Как правило, серверная часть определяет HTTP-ресурсы, предоставляющие требуемое содержимое в формате JSON, которое при необходимости может быть отфильтровано в соответствии с параметрами запроса. Причиной столь широкого распространения формата JSON является то, что клиентский код JavaScript может использовать ответ сервера непосредственно в виде объектов JavaScript, без дополнительных преобразований.
Если клиентский интерфейс развертывается вместе с серверной частью как единый артефакт, то структура проекта требует большей координации. Артефакт содержит оба уровня технологии, они компилируются и собираются в пакеты одновременно в процессе сборки. При разработке такое объединение не является обязательным, если цикл разработки клиентской части отличается от разработки серверной. Программист, который занимается клиентской частью, едва ли захочет каждый раз пересобирать вместе с ней серверную часть. То же самое касается и серверной части, разработчики которой не захотят ждать окончания компиляции и упаковки потенциально медленного JavaScript.
В этих случаях имеет смысл разделить проект на несколько модулей, каждый из которых собирался бы отдельно. Хорошо зарекомендовал себя принцип упаковки клиентской части как отдельного модуля и представления его в виде зависимости для серверного модуля, который затем пакуется отдельно. Таким образом, клиентский модуль может быть собран отдельно, а программист серверной части может пересобирать серверную часть, используя последнюю версию клиентского интерфейса. Благодаря этому сокращается время сборки обеих частей.
Для того чтобы это можно было реализовать, в Servlet API предусмотрены статические ресурсы, не только упакованные в архив, но и содержащиеся в JAR-файлах. Ресурсы, находящиеся в разделе META-INF/resources JAR-файла, который хранится в WAR-файле, также поставляются в контейнере Servlet. Проект клиентской части содержит все необходимые интерфейсные технологии, фреймворки и инструменты и собирается в отдельном JAR-файле. Это позволяет программистам отделять клиентскую часть от серверной, чтобы адаптироваться к их разным жизненным циклам.
Последующий материал будет посвящен серверным технологиям и бизнессценариям, доступ к которым можно получить посредством межкомпьютерного взаимодействия, например с помощью веб-сервисов.
