Design customizable ERP in Spring Boot

Question

We are going to develop ERP which should be customizable for different customers, and also customer can tell which modules need and which not.

For instance: we got modules A, B and C. Customer needs only A and B, where each module will have domain model, business layer, rest api. Also need add another entity into domain model of module A which cause change in database, business process and also rest (changing of rest should cause change of frontend).

We have no experiences with this kind of software so I would ask you for help. Can you tell me what is the best practise for that use-case? What is recommended project structure?

We are thinking about this:

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

This will be our default template and when customer will ask about change we will create another branch for that. Is it good way? What do you think?

Thank you in advice for answers.

Answer 1

what you are looking for is called Feature Toggles (aka Feature Flags)

Feature Toggles is a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system. - Martin Fowler

check these solutions

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

Answer 2

This is a very domain specific question and no one can give you the exact answer without the complete requirements. Since I have been working on ERPs, I will try to give you the hints that how we made our ERP dynamic. It all about the database design

First, you should have a flexible Role-Permission module on Spring Security which can work for every type of user. Like you can create multiple Roles, a Role can have multiple Permissions, and a User can have multiple Roles. This will help you to control things/features on lower level.

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

changing of rest should cause change of frontend

You can achieve it by giving different Roles to Users for different modules and based on that you can redirect them to different dashboard/jsps after login with the help of a CustomSuccessHandler

What is recommended project structure?

Having separate packages for modules is okay but I will prefer more widely used MVC structure on 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

The list of things that you need to keep in the mind while developing ERP will keep increasing but the most important thing is your Database Design not just the project structure and it all depends on business requirements.

Answer 3

Modularity and customization are two different problems in complex software systems like ERP.

First of all, domain-based architecture is not much suitable: there are many intersection and you cannot design every domain independently, you need to clearly define interfaces and common data integrity at least. The modules have a dependency structure that is not plain but hierarchical, i.e. sales and procuration are based on products and clients, production is based on materials and human resources etc.

Secondly, the customization is orthogonal low-level functionnality and can be implemented in a different way: metadata, parametrisation, internal script language or DSL, screen form and query/reporting designers etc. These modules are common for all other.

Also have a look on my old presentation about architecture layers and levels in information system.

Answer 4

Designing and implementing an ERP from scratch isn't an easy task, especially in your case, in which you have zero experience with this kind of application. I'd recommend taking a look at open source ERP/CRM solutions -- Apache OFBiz could be a good option or starting point, since you have some Java expertise. They provide very good documentation and a modular 3-tier architecture, as you mentioned in your question. Frameworks are a little oldie, but serve as a good source of inspiration.

All Apache OFBiz functionality is built on a common framework. The functionality can be divided into the following distinct layers:

Presentation layer Apache OFBiz uses the concept of "screens" to represent the Apache OFBiz pages. Each page is, normally, represented as a screen. A page in Apache OFBiz consists of components. A component can be a header, footer, etc. When the page is rendered all the components are combined together as specified in the screen definition. Components can be Java Server Pages ([JSP]s) , FTL pages built around FreeMarker template engine, forms or menus widgets. Widgets are an OFBiz specific technology.

Business layer The business, or application layer defines services provided to the user. The services can be of several types: Java methods, SOAP, simple services, workflow, etc. A service engine is responsible for invocation, transactions and security. Apache OFBiz uses a set of open source technologies and standards such as Java, Java EE, XML and SOAP. Although Apache OFBiz is built around the concepts used by Java EE, many of its concepts are implemented in different ways; either because Apache OFBiz was designed prior to many recent improvements in Java EE or because Apache OFBiz authors didn’t agree with those implementations.

Data layer The data layer is responsible for database access, storage and providing a common data interface to the business layer. Data is accessed not in object oriented fashion but in a relational way. Each entity (represented as a row in the database) is provided to the business layer as a set of generic values. A generic value is not typed, so fields of an entity are accessed by the column name.