Проекты Scramboot будут сумасшедшие, когда вы создаете каталог!

Spring Boot Java

Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.

После того, как много одноклассников создали проект, мне не терпится начать. Код проекта может быть написан свободно, как некоторый код фреймворка, но обычно он разрабатывается в режиме MVC. Очень грустно, название этих каталогов разработано на Java, теперь все еще беспорядок, вам нужно планировать самостоятельно.

Что Контролёр, Служба, Дао и т.д., а на самом деле у этого метода деления много недостатков!В этой статье сначала будут представлены две типичные иерархические структуры, а затем будет немного использована идея DDD, и будет рассказано о структуре каталогов, которую я обычно использую в проектах. Эта статья очень实用, обсудим, как бороться с大型项目подразделение справочника.

Четкая структура каталогов может помочь другим учащимся легко понять функциональные модули проекта, а также является очень хорошей привычкой поддерживать последовательное общее соглашение в проекте. Если вы добавите еще один扩展性Это подразделение каталогов имеет наивысший приоритет.

Есть два типичных способа категоризации, но также много деталей.

1. Простейший MVC

Что нам больше всего знакомо, так это структура MVC. Эта структура очень популярна, и на ней очень удобно писать простые проекты, но она вызовет серьезные проблемы со связью и проблемы со взрывным ростом службы.Тысячи или десятки тысяч строк кода являются обычным явлением.

  1. Модель (model) представляет собой ядро ​​приложения (например, поля записи базы данных).
  2. Просмотр отображает данные (записи базы данных).
  3. Контроллер обрабатывает ввод (записывает записи в базу данных).

С точки зрения разделения проекта, это похоже на следующую структуру каталогов.

1.1 Модель

Домен — это очень широкое понятие в DDD. Однако мы обычно рассматриваем это как Java, соответствующую базе данных. используемый класс (ничего плохого). На практике он также может иметь следующие имена, в普通项目Разница не большая, смысл в проекте лучше оставить тот же, чтобы не было двусмысленности.

  • entityЭто значение более очевидное, то есть значение сущности, наиболее употребительное. такие как JPAEntityаннотация
  • modelСмысл модели обычно используется для взаимодействия между различными системами. Но если ваша модель очень проста, ее также можно представить непосредственно сущностью.
  • domainЭтот диапазон немного велик и включает даже услуги в полевых условиях. Если вы не очень знакомы с концепцией DDD, то поиграйте в вышеописанное

Для простых проектов я обычно использую сущности в проекте для представления взаимодействия с базой данных. В ORM, таких как JPA, также выполняется соответствующая обработка. Напримерjavax.persistence.Entityаннотация. Что вам нужно понять, так это то, что Spring Data на самом деле берет довольно эклектичную точку зрения и объединяет множество вещей.

1.2 Dao

daoУровень называется уровнем доступа к данным, который называется уровнем доступа к данным.data access object, которая относится к относительно низкоуровневой и базовой операции. В некоторых других фреймворках это называется по-другому.

  • mapperОбычно это каталог, созданный такими фреймворками, как Mybaits, обычно некоторыми интерфейсами.
  • repositoryСкладские средства, в жпа часто используемые.

Dao должен соответствовать принципу минимальной инкапсуляции и теоретически включает только выполнение предложения SQL. Если есть несколько действий доступа к данным, их необходимо инкапсулировать в службу и управлять транзакциями (хотя репозиторий находится в DDD, он не работает с конкретными базами данных).

1.3 обслуживание и контроллер

Об этом особо нечего сказать, в основном вся важная логика сделана здесь. Сервис используется для логической обработки, а контроллер используется для раскрытия интерфейса.

2. Организуйте по функциям

В большинстве случаев мы используем описанный выше режим деления и можем выполнить свою работу. Например, вся обработка данных размещается на уровне Dao, а вся логическая обработка — на уровне Service.

Это прекрасно работает в небольших проектах, но если в проекте сотни или тысячи сущностей, файлы в этих каталогах взорвутся и в конце концов станут неподдерживаемыми.

Другая проблема заключается в том, что просто простая функция может быть разбросана в нескольких файлах под несколькими пакетами, что затрудняет сохранение крупномасштабных проектов.

У нас есть еще одна идея — группировать по функциям. Например скриншот ниже.

Помещаем аналогичные функции вmodulesв одной папке под. Если этот функциональный модуль относительно велик, мы можем выполнить иерархическое проектирование в рамках функционального модуля.

Например, на картинке выше товарный сервис, ему мы присваиваем каталог space goods, а затем делим в нем каталоги dao, entity и другие, а для Сервиса и Контроллера мы просто помещаем его во внешний слой , вы можете видеть, что распределение внутри модуля более гибкое.

Преимущества этого очевидны. Функции стали очень концентрированными, и содержимое каждого пакета не влияет друг на друга.

3. До сих пор недостаточно элегантно

На самом деле, даже если мы разделим его таким образом, проект все равно столкнется с большими проблемами (во многих книгах по DDD много обсуждается взаимодействие каждого слоя).

Позвольте мне поделиться многоуровневым шаблоном, который я обычно использую, принимая во внимание высокую связность и первую связь, и он имеет хорошую масштабируемость.

  1. config, некоторые самые внешние глобальные конфигурации, такие как веб-конфигурация, конфигурация очереди сообщений и т. д.
  2. system, глобальные инструменты и зависимости, называемые инфраструктурой в DDD (но странные имена в проектах, которые не практикуют DDD)
  3. auth, модуль авторизации аутентификации, такой какJWTилиSpring SercurityЭта часть дизайна должна быть независимой, так что после вспомогательного шлюза отсоединена, как Zuul
  4. bc, что означает ограниченный контекст в DDD, мы также можем назвать его напрямую模块, эти модули имеют строгие границы и могут быть请求量, разделенные на соответствующие микросервисы. На картинке вышеcrm,images,orderИ так далее, можно разделить на независимые микросервисы

Давайте еще раз взглянем на структуру внутри каждого модуля.Аналогичен традиционному MVC. Однако, чтобы скрыть изменения и учесть масштабируемость, мы добавили больше контента.

  1. persitence, Уровень сохранения, используется ли JPA или Mybatis, это не имеет значения. Наша цель — максимально ослабить реализацию слоя сохраняемости и инкапсулировать изменения в слое предметной области.
  2. persitence/dao, конкретный интерфейс уровня сохраняемости, такой как файл Mapper MyBatis или JPARepository
  3. domainУровень, конкретный бизнес-уровень, вы можете думать о нем как о связке bean-компонентов Getter и Setter. Мы пытаемся инкапсулировать большинство классов проверки и изменений здесь (что можно грубо представить как модель перегрузки в DDD).
  4. controller, конкретный уровень интерфейса Rest. Но разница в том, что есть много разных запросов и возвратов, которые мы инкапсулируем какRequestиResponse, используемый для принятия отправленных данных, сокращения возвращаемых данных и т. д.
  5. application, чтобы иметь дело с традиционным сервисным уровнем, за исключением того, что приложение может вызыватьDao, другие слои не имеют права называть Дао
  6. api, и функция приложения та же. Однако интерфейс API относится к интерфейсу, с помощью которого модули могут вызывать друг друга. Из этих интерфейсов, предоставляемых API, классы и интерфейсы между bc по умолчанию невидимы друг для друга.
  7. util, неуниверсальные утилиты будут размещены внутри модуля вместо того, чтобы вытаскивать общедоступные утилиты

Помимо решения проблемы каталогов, нам также необходимо четко спланировать поток данных.

Приложение верхнего уровня может напрямую вызывать службы нижнего уровня через интерфейс API. Например, система заказов может получить доступ к данным базовой информации о товарах, в противном случае это невозможно, например, к интерфейсу модуля базовой информации о товарах, доступ к системе заказов.

Хотите внести изменения в более низкий уровень данных, это только через модуль новостей, изменит выпуск, другие модули могут подписаться на эти изменения.

резюме

В итоге,xjjdogСчитается, что если ваш проект может быть относительно большим, не стоит просто использовать многоуровневый пакет.

Возможно, вы знакомы с таким проектом управления фоном, есть много полезных шаблонов, все они представляют собой простые слои MVC. Это может быть не проблема для работы с некоторыми аутсорсинговыми проектами и выполнения некоторых разовых транзакций, но когда это относительно большой и долгосрочный проект, этот многоуровневый интерфейс каталогов покажет свои недостатки.

Это связано с тем, что краткосрочный риск проекта связан с периодом строительства, а долгосрочный риск связан с расширением. С увеличением количества посещений и растущим спросом на низкую связанность и высокую связность, то, как быстро реагировать на спрос и уменьшать количество ошибок, будет наиболее важным фактором, ограничивающим развитие проекта.

Об авторе:Мисс сестра вкус(xjjdog), публичная учетная запись, которая не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус. Мой личный WeChat xjjdog0, добро пожаловать в друзья для дальнейшего общения.​