Structuring Java applications is important for large projects with many developers. There are different approaches like putting everything in one package, packing by technical layers, or packing by feature. Packing by feature has better structure with high cohesion and low coupling, but public modifiers are needed which can leak internal information. Common problems are limited encapsulation and wrong method invocations due to leaked information. Solutions include using internal packages with interfaces/factories, API packages with conventions and code analysis, and Java Platform Module System. An example shows how implementation details can overwhelm and how to better hide information between modules.

1. Slide 1
Structuring your Java application
黃俊喬 Woody Huang
woody0927@gmail.com
2019.10.4

2. Slide 2
Background
Our Product:
▪ Monolith
▪ More than 10 years of development
▪ More than 10 developers working on the project
Problems:
▪ Not possible to know/remember everything of the system
▪ Inefficient or even fail to find suitable reusable method
▪ Redundant code
▪ Wrong method invocation
▪ Runtime environment is not controlled by us

3. Slide 3
Outline
▪ Different approaches to structuring your application
▪ Pros and cons of each approach
▪ Common problems and solutions
▪ Example

4. Slide 4
Different approaches to structuring your application
▪ Everything in one or a few classes
▪ Packing by technical layers
▪ Packing by feature
▪ Grouping relevant features into module

5. Slide 5
Everything in one or a few classes
Concept: Putting all classes in one package
Pros:
▪ No-brainer design
Cons:
▪ Hard to maintain
▪ Hard to debug
▪ Changes are prone to error

6. Slide 6
Packing by technical layers
Concept: All classes in the package are of the same type, e.g. Service.
Collaboration among packages are usually required to complete a feature.
Pros:
▪ Easy and better structured
▪ Information is at certain level protected
▪ Changes sometimes can be localized to one layer
Cons:
▪ Low cohesion and high coupling
▪ High Ripple effects
▪ Modifiers have to be public for cross package access
▪ Internal information leaked via public modifier

7. Slide 7
Packing by feature
Concept: Classes get used together are putting together
Pros:
▪ Even better structured - high cohesion and low coupling
▪ Information is protected
▪ Minimizing ripple effects
Cons:
▪ Modifiers have to be public if we create sub-packages
▪ Internal information is leaked via public modifier

8. Slide 8
Grouping relevant features into module
Concept: Features having same domain concept are putting together
and form an multi-module project. This is used together with grouping
by feature / technical layers and inherits the pros and cons.
Pros:
▪ Most of changes can be isolated to one module

9. Slide 9
Common problems to different grouping approach
▪ Limited encapsulation
▪ public modifier is inevitable - enterprise application is unlikely to
be built without sub-packages
▪ Confusions and wrong method invocations due to leaked
information

10. Slide 10
Solutions
▪ internal package - works with interface and factory to get the
runtime instance (regulated by convention)
▪ api package - (regulated by convention and code analysis rule)
▪ Java 9 - Java Platform Module System whenever possible

11. Slide 11
Example: Overwhelmed by implementation detail
Module: Onboarding
Module:
Risk-assessment
ClientService
+ register
+ backgroundCheck
+ listProspectClients
+ listRealClients
+ …..
listRealClients

12. Slide 12
Example: API exposure - information hiding
Module: Onboarding Module: Risk
assessment
ClientSe
rvice
+ …... listRealClients
API
listRealClients

13. Slide 13
Reference
▪ Sample: https://github.com/woody0927/structuring-java-app
▪ Package by feature, not layer
▪ Package by type, -by layer, -by feature vs “Package by layered feature”

14. Slide 14
QUESTIONS & DISCUSSIONS