Когда дело доходит до слова «архитектура», будет много существительных, таких как: многоуровневая архитектура, архитектура, управляемая событиями, DDD, CQRS и т. д. Или куча принципов проектирования программного обеспечения, таких как: принцип KISS (Keep it Simple and Stupid), принцип SOLID (принцип единой ответственности, принцип открытости-закрытости, принцип подстановки Лискова, принцип разделения интерфейсов, принцип опережения зависимостей) и так далее. Даже моделирование UML, такое как диаграмма состояний, диаграмма вариантов использования, диаграмма последовательности, диаграмма действий, шаблон проектирования GOF и т. д.
В этой статье не будут обсуждаться эти архитектурные концепции, но мы начнем с бизнес-сценария на странице сведений о Xianyu, проанализируем текущие бизнес-проблемы и болевые точки, а затем решим эти болевые точки путем пошагового создания и проектирования архитектуры. С развитием бизнеса, я считаю, что с этими проблемами столкнется каждый. Процесс решения проблемы будет более или менее использовать вышеуказанные принципы проектирования.
фигура 1
Определение архитектуры
Когда многие студенты начинают писать бизнес, они в основном сначала строят таблицы, затем генерируют CURD и, наконец, накапливают бизнес-логику, прописывая весь путь от DAO-> Manager-> Service-> Controller до конца. Когда бизнес небольшой, эта архитектура очень проста и практична, и ее можно быстро разработать и запустить.
Однако с развитием бизнеса и постоянным увеличением персонала старая архитектура не может поддерживать развитие бизнеса, а стабильность и эффективность оказываются под большим вопросом. Эпоха варварства прошла, наступает эпоха интенсивного выращивания, и для поддержки развития бизнеса срочно нужна более подходящая структура.
Взяв в качестве примера страницу сведений Xianyu, на ранней стадии бизнеса был только один тип сведений в виде обычных участников торгов. Назовите сегментированный бизнес «вертикальный бизнес»).
фигура 2
Страница сведений об эволюции бизнеса Xianyu
В настоящее время к старой бизнес-логике постоянно добавляется новая бизнес-логика, в результате чего вся подробная бизнес-логика накапливается. В результате возникнут следующие сценарии: 1) Сегодня одноклассники бизнес-линии детали А добавили сегмент логики и повесили трубку, затронув всех студентов бизнес-линии; 2) Студенты бизнес-линии детали из B хотят сделать отдельный мониторинг и кэширование, понижение версии и т. д., это невозможно, логика у всех общая, а стоимость преобразования слишком высока; 3) Студенты в бизнес-линии C детализировали, чтобы сосредоточиться только на С подробно описывает бизнес-логику, но обнаружил, что все бизнесы были вместе, и им пришлось объединить все бизнесы. 4) Студенты бизнес-направления D детализировали бизнес-логику, которая была слишком сложной. Чтобы свести к минимуму влияние, они нашли место, которое, по их мнению, было самым безопасным, и добавили специальную обработку для бизнеса с деталями D.
изображение 3
Логический код кучи страницы сведений
Некоторые люди могут спросить, логика кучи это нормально, добавьте несколько строк кода, и бизнес будет в сети.Гибкая разработка, которую пропагандирует Интернет, конечно же, происходит максимально быстро. А гибкая разработка!= повышение спроса + кодирование + публикация, добавление нескольких строк кода для доставки бизнеса в онлайн, может принести немедленную пользу, но если так будет продолжаться, код будет становиться все более и более раздутым, а системы с дизайном не будет и документацию, которую трудно поддерживать, это только вопрос времени, когда она выйдет из строя.
03 Новая бизнес-архитектура — изоляция бизнеса + моделирование предметной области
Закон Гидлина гласит: четко запишите проблему, и вы уже на полпути к ее решению. Проблемы старой архитектуры можно резюмировать следующим образом:
1) Бизнес не изолирован, а все вертикальные бизнес-логики сложены вместе и влияют друг на друга.
2) Бизнес страницы сведений достаточно сложен, но нет единой модели для формирования единого познания. Поэтому проектирование архитектуры направлено на решение этих двух задач.
1Вывод и проектирование архитектуры изоляции бизнеса
Бизнес имеет несколько форм реализации, и шаблону стратегии легко соответствовать в шаблоне проектирования. Грубо говоря, каждый вертикальный бизнес реализует собственную страницу сведений.
Рис. 4. Использование шаблона стратегии для изоляции реализации каждого бизнеса
Таким образом, хотя бизнес изолирован, стоимость обслуживания чрезвычайно высока.Чтобы добавить общую функцию, все бизнесы должны быть добавлены снова. Следовательно, необходимо абстрагироваться от общего содержания (неизменной части) и реализовывать измененную часть каждым вертикальным бизнесом.
Рис. 5 Абстрагирование содержания общности (без изменений) и характеристик (изменения)
Таким образом, устраняется изоляция бизнеса, общий контент поддерживается единообразно, а измененные части независимо поддерживаются каждым вертикальным бизнесом. Но в это время все бизнес-команды все еще пишут бизнес-код в проекте приложения, и возникнут следующие сценарии: 1) На этапе разработки каждое бизнес-направление тянет ветку в этом приложении для разработки, и конфликты кода неизбежны во время комплексное развертывание. 2) Бизнес-направление добавляет логику своего собственного бизнес-направления, и развертывание завершается сбоем, делая другие бизнес-направления непригодными для использования. 3) Бизнес-линия N не находится в своей команде, а принадлежит команде внешнего сотрудничества.Как добавить логику этой бизнес-линии.
Причина существования этих сценариев заключается в том, что хотя бизнес-код изолирован, процесс развития персонала — нет. Есть 3 метода на выбор:
А. Включите общий контент в двухсторонний пакет зависимостей, и каждый вертикальный бизнес полагается на этот двухсторонний пакет для независимой разработки приложений.
Этот метод двухсторонней зависимости используется чаще всего, но при добавлении общей функции к сторонней службе все бизнес-стороны должны быть проинформированы о необходимости обновления стороннего пакета и выпуска версии, обновление которой обходится дорого.
Рисунок 6.а
Общий контент упакован в двухсторонний пакет
B. Независимая разработка приложений для вертикального бизнеса, затем упаковать код в пакет jar, затем интегрировать его в общее бизнес-приложение и развернуть вместе.
Зависимость метода противоположна методу а, но метод развертывания недостаточно гибкий. Если вы хотите добиться независимого развертывания вертикального бизнеса, стоимость трансформации слишком высока, вам нужно делать изоляцию классов, изоляцию будлов и т. д.
Рисунок 6.б
Двухсторонний пакет вертикального бизнеса
в) Сочетая преимущества вариантов а и б, общий бизнес можно развернуть независимо, а вертикальный бизнес можно развернуть независимо или написать в приложении с общим контентом. При вызове вертикальной бизнес-реализации он может быть автоматически перенаправлен на конкретную вертикальную бизнес-реализацию (эта вертикальная бизнес-реализация может быть локальным вызовом или удаленным вызовом). Таким образом, разработчики вертикальных предприятий могут разрабатывать, развертывать и поддерживать приложения в своих собственных приложениях, решая проблему изоляции разработчиков.
Рисунок 6.с
Независимо друг от друга, необязательный метод развертывания
На данный момент проблема изоляции бизнеса и изоляции разработчиков решена. Однако очевидно, что эта архитектурная схема доступна не только в подробном сценарии, другие подобные бизнес-сценарии также имеют аналогичные проблемы. Следовательно, код архитектуры не может быть связан с кодом бизнеса. Необходимо отделить код архитектуры, чтобы сформировать общий технический инструмент, который можно применять ко всем подобным бизнесам. Развитие бизнеса должно заботиться только о бизнес-вопросах. . Для этой цели мы специально разработали мультиреализационный инструмент маршрутизации "бизнес-изоляции". Окончательная схема архитектуры изоляции выглядит следующим образом:
Рисунок 7
Общая схема архитектуры
2Использование модели предметной области на странице сведений
Проблема изоляции решена, поговорим о моделировании предметной области страницы деталей.
Зачем вам нужно моделирование предметной области? Многие студенты, разрабатывающие java, столкнутся с такими проблемами: 1) На ОО (объектно-ориентированном) языке написанный код не имеет ощущения ОО, но он похож на процедурный код, и в принципе нет объектно-ориентированной идеи. использовал к. 2) Хотя код удовлетворяет бизнес-требованиям, от кода вообще нет тени бизнес-домена, а бизнес-домен и код разъединены. 3) По мере усложнения бизнеса разобраться в зависимостях внутри очень сложно, а бизнес-модуль вообще не имеет границ.
Чтобы не копать дыры для будущих поколений, чтобы решить сложную логику страницы сведений, чтобы сделать код более стандартизированным и чтобы студенты, которые берутся за детали, имели единое понимание предметной области, мы решили смоделировать предметную область.
Рисунок 8
Проектирование, управляемое предметной областью — общая схема взаимосвязей моделей
Уже более десяти лет популярна классическая книга Эрика Эванса «Domain-Driven Design — How to Cope with Software Core Complexity». моделирование цветового прототипа. Существует также множество абстрактных методологий для моделей предметной области проблемного пространства. Но в этих статьях и книгах либо говорится о теоретических понятиях, либо о методах моделирования, а новички после прочтения еще не умеют писать соответствующий код.
Поэтому в этой статье не повторяется концепция моделирования предметной области, а непосредственно описываются этапы моделирования и отображение кода DDD через бизнес-сценарий страницы сведений Xianyu, предоставляя читателям более интуитивно понятный справочник.
3Подробное моделирование домена страницы
Страница сведений Xianyu — это чистая страница отображения, которую можно резюмировать одним предложением: «Страница сведений — это страница отображения агрегации информации, включая: продукты, продавцов, покупателей, рыбные пруды, сертификацию, взаимодействие и т. д.».
Здесь мы используем для моделирования четырехцветный метод моделирования прототипа. Основное содержание приведенного выше предложения: страница сведений — это «страница отображения агрегации информации» (мгновенное событие).
Рис. 9. Страница сведений — это страница отображения агрегированной информации
После того, как основное содержимое определено, чтобы лучше описать, что представляет собой страница сведений, необходимо добавить некоторые объекты сущностей.Страница сведений в основном включает сущности (человек-объект-место), такие как товары, продавцы, покупатели и рыбные пруды. .
Рис. 10. Основные объекты, включенные в страницу сведений
На этой основе осуществляется дальнейшая абстракция: в сущности-пользователе имеются роли продавца и покупателя, в сущности-водоводе также роли владельца пруда и гражданина пруда (владелец пруда также является гражданином пруда). , поэтому владелец пруда должен унаследовать Тан Миня). Модель после добавления роли показана на рисунке 11:
Рис. 11. Роли на странице сведений
Наконец, поместите в него некоторую описательную информацию,
Рисунок 12 Дополнительная информация описания в модели
При проектировании модели переходят к проектированию диаграммы классов. В соответствии с абстракцией модели страница сведений представляет собой агрегацию отображения информации, поэтому она является корнем агрегации, который содержит информацию об объектах, такую как товары, продавцы, покупатели и рыбные пруды. В описании информации о продукте есть видео, изображения, тексты, взаимодействия и другая информация. Видео и изображения можно абстрагировать как медиаинформацию. Используйте UML для разработки окончательной диаграммы классов, как показано на рис. 13:
Рис. 13. Структура диаграммы классов страницы Details
Отображение кода 4DDD
С доменом для модели модель необходимо переназначить на код. При реализации страницы сведений она основывается на определении в DDD. Основное содержимое DDD включает в себя: сущность, объект значения, агрегат, репозиторий, фабрику и службу (как показано на рисунке 8), а также иерархическую структуру инфраструктуры, домена, приложения и пользовательского интерфейса, как показано на рисунке 14:
Рисунок 14
Многоуровневая архитектура проектирования на основе предметной области
Инфраструктура в основном используется для чтения и записи постоянных данных; Домен — это уровень домена, который предоставляет информацию о домене, которая является ядром бизнеса; Приложение — это тонкий слой без бизнес-логики, используемый для координации действий приложения; Пользовательский интерфейс Отвечает за пользователя информационный дисплей. Сопоставление этой иерархии со структурой проекта показано на рисунке 15.
Рисунок 15
Инженерная структура моделирования предметной области DDD
Слой приложения здесь не имеет бизнес-логики и предоставляется только как сторонняя служба. Кроме того, слой пользовательского интерфейса не прописан в структуре проекта, потому что приложение предоставляется как сторонний сервис.Конечно, если предоставляется REST-сервис, его можно прописать в этом слое.
Большинство пользователей знакомы с архитектурой MVC, поэтому на рис. 16 для справки сравниваются многоуровневая архитектура DDD и архитектура MVC.
Рисунок 16
Многоуровневость DDD и многоуровневость MVC
В соответствии с приведенной выше абстракцией модели объекты домена в основном включают ItemEntity, SellerEnity, BuyerEntity, FishPoolEntity и агрегируются через корень агрегата страницы сведений DetailAggregate.
Рисунок 17
Корень агрегата страницы сведений
В иерархии структуры приложения на рис. 15 есть три типа объектов данных: объекты DO представляют постоянные объекты данных, Entity — объект домена, а DTO — объект внешней передачи.
Сначала через репозиторий уровня домена вызовите Dao уровня базовых настроек, чтобы прочитать структуру DO, а затем с помощью преобразователя преобразуйте его в объект домена Entity.
Рисунок 18
Определение репозитория
Рис. 19 Определение преобразователя преобразователя
Объект домена обрабатывает свою собственную бизнес-логику домена, а затем обрабатывает бизнес-домен общей страницы сведений для сводного корня DetailAggregate через службу DetailService уровня домена. Наконец, он преобразуется в объект передачи DTO для предоставления внешних услуг.
04 Подведите итоги и подумайте
Эта статья начинается со страницы сведений о бизнесе. Когда бизнес становится все более и более сложным, как изолировать бизнес, изолировать разработчиков и как сформировать единое познание посредством моделирования предметной области. Чтобы предоставить вам возможную ссылку.
Ни одна архитектура не может быть применена ко всем сценариям, и ни одна архитектура не является оптимальной.Все так называемые архитектуры решают проблему «границы». Поэтому необходимо начать с реального бизнес-сценария, уточнить, где проходит граница проблемы, какую цель достичь, а затем следовать некоторым основным принципам и методам, и в принципе уметь проектировать архитектуру, соответствующую вашим собственные деловые качества. Далее я поделюсь с вами дизайном бизнес-архитектуры с разных точек зрения.Пожалуйста, продолжайте обращать внимание на официальный аккаунт.
Google Developers Conference 2018 Приложение TensorFlow "UI 2 Code"
Тысячи людей и тысячи лиц онлайн выявили проблемы с технологией воспроизведения
Как фильтровать данные любого измерения из десятков миллиардов таблиц за миллисекунды...