1

I am writing code on top an established Enterprise application. I see that the application has 4 modules as shown below.

-Srk
-SrkEJB
-SrkUtils
-SrkWeb

I have gone through the code and I see that some modules are tiny for example: SrkEJB module has got just 2 EJBS. I don't see any reason to create a separate module for 2 Java classes.

I have simplified the above approach and is shown below.

Srk
 - com.srk.utils
 - com.srk.ejb
 - com.srk.web

How is the first module based architecture different from the second from an architectural stand point? Generally, which is the followed mostly, when creating an application from scratch? If not, What could be the trade-offs of each of the approaches? I believe this is a not specific to Java alone.

2
  • 7
    Generally speaking, there is no right way to organize classes. There is only the way that best meets the projects requirements for clarity. The size of the modules is probably the least important organizing principle. Commented May 16, 2015 at 6:06
  • 3
    Your question title sounds like a rant - since "module based" is what you consider not to be normal.
    – Doc Brown
    Commented May 16, 2015 at 6:59

2 Answers 2

2

Generally speaking, there is no right way to organize classes. There is only the way that best meets the projects requirements for clarity. The size of the modules is probably the least important organizing principle.

– Robert Harvey

2

Modular design is about separation of concerns, NOT about splitting something up into smaller sections (though it tends to have that effect).
It's perfectly acceptable (and even very good practice) to have a separate EJB module, web module, etc.. Each is its own deliverable after all within the JEE landscape, with the EJB module creating an EJB jar, the web module a WAR, and the utils module a jar file referenced by both.
So your environment is suggesting the modules, enforcing it even through most build tools.

Not the answer you're looking for? Browse other questions tagged or ask your own question.