Разработка настраиваемой ERP в Spring Boot

Question

Мы собираемся разработать ERP, которая должна быть настраиваемой для разных клиентов, а также клиент может сказать, какие модули нужны, а какие нет.

Например: у нас есть модули A, B и C. Потребности клиентов толькоA и B, где каждый модуль будет иметь доменную модель, бизнес-уровень, остальные API.Также необходимо добавить еще одну сущность в модель предметной области модуля A, которая вызывает изменение в базе данных, бизнес-процессе, а также отдыхает (изменение остатка должно вызывать изменение внешнего интерфейса).

У нас нет опыта работы с этим видом программного обеспечения, поэтому япопросил бы вас о помощи.Можете ли вы сказать мне, что является лучшей практикой для этого варианта использования?Какова рекомендуемая структура проекта?

Мы думаем об этом:

root/
 - Module A/
 - - domain/
 - - service/
 - - api/
 - Module B/
 - - domain/
 - - service/
 - - api/
- Angular Module
- - Modle A Components
- - Modle B Components

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

Спасибо в совете за ответы.

Answer 1

то, что вы ищете, называется Feature Toggles (он же Feature Flags)

Feature Toggles - это мощная техника, позволяющая командам изменять поведение системы без изменения кода.Они попадают в различные категории использования, и важно учитывать эту категоризацию при реализации и управлении переключателями.Тумблеры привносят сложность.Мы можем контролировать эту сложность, используя методы реализации интеллектуальных переключателей и соответствующие инструменты для управления нашей конфигурацией переключателей, но мы также должны стремиться к ограничению количества переключений в нашей системе.- Мартин Фаулер

проверить эти решения

• https://www.togglz.org/
• https://ff4j.github.io/

Answer 2

Модульность и настройка - две разные проблемы в сложных программных системах, таких как ERP.

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

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

Также посмотрите мою старую презентацию о уровнях и уровнях архитектуры в информационной системе .

Answer 3

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

Во-первых, у вас должен быть гибкий Role-Permission модуль на Spring Security, который может работать для любого типа пользователя.Как вы можете создать несколько Roles, Role может иметь несколько Permissions, а User может иметь несколько Roles.Это поможет вам контролировать вещи / функции на более низком уровне.

       USER<----ManyToManyBridge--->ROLE<----ManyToManyBridge--->PERMISSION

изменение покоя должно вызывать изменение внешнего интерфейса

Этого можно добиться, задав разные значения Roles - Users для разных модулей и основываясь на этом.Вы можете перенаправить их на разные dashboard/jsps после входа в систему с помощью CustomSuccessHandler

Какая рекомендуемая структура проекта?

Хорошо иметь отдельные пакеты для модулейно я бы предпочел более широко используемую структуру MVC на root.

Root/
- Controller
-- Module1
--- Controller
--- Controller
-- Module2
--- Controller
--- Controller
- Model
-- Module1
--- Model
--- Model
-- Module1
--- Model
--- Model
- Repository
  ...
  ...
- Service
  ...
  ...

- WEB-INF
-- Views
--- Module1
---- .jsp
---- .jsp
--- Module2
---- .jsp
---- .jsp

Список вещей, которые вы должны держать в уме при разработке ERP, будет продолжать расти, но самое важное - это ваша база данных , а не только структура проекта, и все зависит от требований бизнеса.

Answer 4

Разработка и внедрение ERP с нуля - непростая задача, особенно в вашем случае, когда у вас нет опыта работы с такого рода приложениями.Я бы порекомендовал взглянуть на ERP / CRM-решения с открытым исходным кодом - Apache OFBiz может быть хорошим вариантом или отправной точкой, поскольку у вас есть некоторый опыт работы с Java.Они предоставляют очень хорошую документацию и модульную 3-уровневую архитектуру , как вы упомянули в своем вопросе.Фреймворки немного устарели, но служат хорошим источником вдохновения.

Все функции Apache OFBiz построены на общей основе.Функциональность можно разделить на следующие отдельные уровни:

Уровень представления Apache OFBiz использует концепцию «экранов» для представления страниц Apache OFBiz.Каждая страница, как правило, представляется в виде экрана.Страница в Apache OFBiz состоит из компонентов.Компонентом может быть верхний и нижний колонтитулы и т. Д. При отображении страницы все компоненты объединяются, как указано в определении экрана.Компонентами могут быть страницы сервера Java ([JSP]), страницы FTL, построенные на основе движка шаблонов FreeMarker, виджеты форм или меню.Виджеты - это технология OFBiz.

Бизнес-уровень Бизнес-уровень или прикладной уровень определяет службы, предоставляемые пользователю.Сервисы могут быть нескольких типов: методы Java, SOAP, простые сервисы, рабочий процесс и т. Д. Сервисный механизм отвечает за вызовы, транзакции и безопасность.Apache OFBiz использует набор технологий и стандартов с открытым исходным кодом, таких как Java, Java EE, XML и SOAP.Хотя Apache OFBiz построен на концепциях, используемых Java EE, многие из его концепций реализуются различными способами;либо потому, что Apache OFBiz был разработан до многих недавних улучшений в Java EE, либо потому, что авторы Apache OFBiz не согласились с этими реализациями.

Уровень данных Уровень данных отвечает за доступ к базе данных,хранение и обеспечение общего интерфейса данных для бизнес-уровня.Доступ к данным осуществляется не объектно-ориентированным способом, а реляционным способом.Каждый объект (представленный в виде строки в базе данных) предоставляется бизнес-уровню в виде набора общих значений.Родовое значение не вводится, поэтому к полям объекта можно обращаться по имени столбца.