Advice on separating parts of java web application

I'm creating a Java Web Application that predicts bitcoin price. I have 3 important "parts" there:

1. Web Stack(Spring+Thymeleaf+Hibernate)
2. Part that parses API and save btc prices into a database
3. Machine Learning model that takes the data from a database and automatically update itself.

Now these parts are in a single jar stored in different packages. I feel they're completely different and storing them in distinct packages is not enough!

I believe that they should be somehow independent: for example, if there is an internal server error, I don't want to shutdown the self-optimizing of machine learning model just to see what's happened with Tomcat.

My business logic should work continuously and each part should work independently of any parts that it doesn't need. Maybe they should be in three different jars? Did anyone have experience with it? Or maybe someone knows how different logic parts are separated in a big enterprise projects?

IMHO

There are 2 different aspects that you are raising

• ‘Package question’ - this is about code organisation / modularisation
  This helps to keep code modular so you can separately build and test parts of code not directly coupled.

• ‘Internal server error should not stop ML’. This is deciding how many runtime components / sub components - you are running.
  In your case - there appear to be 2 services - UI & ML.
  You can run choose to run

• 1 app with 2 services (as you are doing now)

• or 2 distinct apps with 1 service each

  Based on complexity, runtime demands, ….etc you can choose either

3. Is your application code fail-safe
   For either of the options - require that you build the service parts to be fail-safe for the common use-cases i.e. exception handling to ensure that container does not crash for expected errors. (INFRA failures, etc … are not with in the scope of this)

Note: if the services are sufficiently fail-safe for common use-cases, you can live with 1 APP.

If you choose 2 distinct apps (1 each for UI and ML), it makes sense to split the code into 2 sub-projects

• UI
• ML
• the question of the common code (as 3rd) needs to be decided based on the amount of code-sharing ( I am guessing ML is lighter on the DB)