Where to Put Business Rules?

Suppose you have a simple app that has a text field for the user to type in the price of a meal and a label to display the amount of the tip (15% of the price of the meal).

I understand that the UI code (text box and label) goes in the UI.java file, but where do you put the calculation? Should be in a separate file, but where do you put that file?

And just to clarify…

The above is a trivial example and the calculation would obviously go into the UI.java file. I was trying to use a simple example to help me understand a more complex situation where a large set of business logic and rules should go into its own .java file, to keep things modular and decoupled. I think all of the .java source code files go into the same folder that the UI.java file is, but I just wanted to make sure.

If it matters, for my local development, I am using NetBeans on a Mac. The path to the UI.java file is: MyApp > src > main > java > com > mycompany > myapp > MyUI.java

Vaadin book gives some simple examples how well know application architectures can be applied to the Vaadin.


Thanks. That was information on how to create the architecture of the model, but my question remains:
Where do you put the .java files?
The link (under Fig. 11.11 source code) said only “You could add the view anywhere in a Vaadin application, as it is a composite component.”

I think all of the .java source code files go into the same folder that the UI.java file is, but I just wanted to make sure.

There is no right answer and it really depends on the conventions you use. E.g. you can go with structure “com > company > app > business > usecase” and for the UI " com > company > app > client > vaadin > [ui | model | usecase ]
" or any other combination.

Thank you. Makes much more sense now. I think there was a big leap from “where to put your code” to application architecture. The middle step of
to organize your code was missing.

May I suggest that you add just a mention of this very helpful information to the Book of Vaadin? One possible way is to put something like the following at 4.2.1 (
bold section
is the suggested addition):

4.2.1. Application Architecture

Once your application grows beyond a dozen or so lines, which is usually quite soon, you need to start considering the application architecture more closely. You are free to use any object-oriented techniques available in Java to organize your code in methods, classes, packages, and libraries.
This means you (or your IDE) can set up your Java source code directory structure any way you like, according to Java package conventions. As you gain more experience with Vaadin, you may find a need to separate your code into a UI java file, a business rules .java file, etc. These files can be placed in the same folder or in different ones, according to how you want to structure your source code directory. For further information, refer to Java package conventions or how WAR files are created.
An architecture defines how these modules communicate together and what sort of dependencies they have between them. It also defines the scope of the application.

You should organize your class and package structure in any way that clearly separates the function or purpose of the classes - UI classes, business classes, etc. Vaadin doesn’t have any requirements for that; the only technical exception is client-side code to be compiled with the GWT compiler, which must be under a “client” package (by default).

The book should indeed give some example about that. My a bit old (Vaadin 6) application example, Gas Diary, gives one example of basic code modularization.
Browse the package structure here

Usually you have business domain model entities, UI classes, views, general-purpose composite components, custom components, and utilities in different Java packages. You can find plenty of (general) articles about the topic, for example
this SOF article

For example:

  • com.example myapp.MyAppUI - typically under 100 lines
  • com.example myapp.MyAppServlet
  • com.example.myapp.model.Dish - a business bean/POJO
  • com.example.myapp.model.Menu - a business bean/POJO
  • com.example.myapp.model.Meal - a business bean/POJO
  • com.example.myapp.ui.DishEditor - a composite form for editing a business bean
  • com.example.myapp.ui.MenuEditor - a composite form for editing a business bean
  • com.example.myapp.ui.MyComponent - server-side API of a custom widget
  • com.example.myapp.view.LoginView (these could be under the .ui package)
  • com.example.myapp.view.MenuView
  • com.example.myapp.view.MealView
  • com.example.myapp.util.DBUtil
  • com.example.myapp.persistence.MyQuery
  • com.example.myapp.widgetset.MyAppWidgetset
  • com.example.myapp.widgetset.client.MyWidget
  • com.example.myapp.widgetset.client.MyWidgetConnector …etc
  • com.example.myapp.widgetset.public/mycomponent/styles.css
  • etc.