The business logic is implemented in an ERP module.
The business logic will be stored in similarly named and structured folders as the entities or modules that it serves.
Business logic can be called directly when the service can directly access the database or via API in case a service is disconnected from the database. Mode switching should be handled automatically and overrides should be possible.
Usually the business logic should be used trough its corresponding microservice but some logic can be used directly (example: validating a field or extracting processed values).
The business logic should be live-updatable, i.e. replacing source code or compiling the application shouldn’t interrupt the processes for too long.
All business logic blocks (methods, loops) should be as short and modular as possible in order to easily identify changes.
All logic blocks should be commented with a brief description on what the block does.
1.1. Logic Repository
Certain rules will be in place for entity processing. That logic will be implemented in a repository.
All data access should pass through a repository in order to use the log table and other audit functionality.
1.1.1. Base repository
The base repository will contain business validation and logic common to all entities, for example making sure the id respects the specifications, the user is allowed to access the data, writing to the log tables etc.
The ORM operations should be private inside the repository or override in order to implement the base repository functionality.
1.2. Extending business logic
Business logic should implement interfaces.
All business logic (custom especially) should be enabled from database configuration tables.