Создание настраиваемой ERP в Spring Boot

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

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

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

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

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

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

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

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

Также обратите внимание на мою старую презентацию о .

Это очень специфический вопрос для предметной области, и никто не может дать вам точный ответ без полных требований. Поскольку я работаю над 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, будет постоянно увеличиваться, но самое важное - это ваш Дизайн базы данных, а не только структура проекта, и все зависит от по бизнес-требованиям.

то, что вы ищете, называется переключателями функций (также известными как флаги функций)

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

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

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