Question

When I say “EJB” here, I mean EJB 3.x!

I’m new to EJBs and am wondering how to best map all of my business logic to different beans. At one extreme, you could KISS and just have one monolithic EJB that has a bazillion methods that handle 100% of your app’s business logic. On the other extreme, you could partition your business logic up to the function-level (List<User> getUsersFromMars()) and have a bazillion EJBs that consist of 1 package, 1 class, and 1 method each:

Extreme #1:
    my-ejb.jar/
        com.me.myorg.MonolithicBean
            List<User> getUsersFromMars();
            List<User> getUsersFromVenus();
            //... a bazillion methods

Extreme #2:
    my-mars-ejb.jar/
        com.me.myorg.MarsBean
            List<User> getUsersFromMars();
    my-venus-ejb.jar/
        com.me.myorg.VenusBean
            List<User> getUsersFromVenus();
    //... a bazillion EJBs with 1-and-only-1 method each

Obviously, I would imagine that best practices dictate some kind of intermediary strategy between these two extremes. So I ask, what does Java/Oracle say about decomposing your app’s business logic down into beans, and how to modularize them at the correct level (EJB, package, class or method) so as to be reusable, scalable and secure?

Answer 1

I think this question is not really specific to EJBs, but is more about OO design, and even general design.

An often recurring pattern is that you can split up your business logic into DAOs and Services. A DAO handles all operations related to a single (domain) entity, like Customer. It interacts only with a data source (typically a database), and has methods like save, update, delete, but also getBySomething methods. Such DAOs can typically have between 1 and ~15 methods, depending on your specific business case.

Then you have Services that as a rule of thumb interact with more than 1 entity and/or interact with other systems (like JMS queues, Mail systems, Web Services, etc) and perform validation/provide security. These form the verbs of your business logic, and typically centralize around a specific business concept, like e.g. a Purchase. So you could have a hypothetical PurchaseService, with methods like purchaseGood, purchaseOffer, calculateReduction. Again, this would have anywhere between 1 and something like 15 or 20 methods.