6

I need to refactor a Java EE application because the current design isn't very modular, in fact it is quite a mess. There is a Business Facade but as the application has been developed by several people and therefore the original design has been ignored several times. The application is currently running on tomcat with JSF but it will be ported to websphere soon. I already did some research about different design patterns to encapsulate the business logic from the view and also how to make the application modular so that it will be easy to put more functionality to it because the application will be enhanced in the future . I've read about OSGI but I think that would be an overkill.

The application is already split into layers. But I'm far away of defining API's. I've already cleaned up the application a bit. Now all the beans access the business logic through the business facade methods. But the business facade consists of about 40 methods which I think isn't very nice.

3rd party edit

For example I have these model classes

  • ManageLdap with methods like createAccount and deleteAccount
  • GroupManager which manages the ldap groups

In the business facade I have a method createAccount which

  • calls the ManagerLdap class to create an ldap account and
  • does some logging and also
  • calls GroupManager

This pseudo code

package Model.ManageLdap

public class ManageLdap 
{
  public ldapAccount createAccount() {  }

  public ldapAccount deleteAccount() {  }
}

public class GroupManager
{
  public bool addAccountToGroup(var account) {  }
}

And in the business facade 

package BusinessFacade.Foo

public class SomeFoo
{
  public ldapAccount createAccount() 
  { 
    var ldapAccount = new ManageLdap.createAccount();
    Logger.log("Account created");
    var accountWasAdded = GroupManager.addAccountToGroup(ldapAccount);
  }     
}

Now if I want to put additional functionality to the application like the option to create a subversion repository for a user

  • i have to implement a model class to create repos,
  • put some methods in the business facade and
  • create an additional bean to be accessed by the view.

That makes the facade even bigger and confusing but beside that, this isn't what I call a modular design.

So how can I seperate the business logic from the view without having a huge business facade?

surfmuggle
  • 5,527
  • 7
  • 48
  • 77
secador de pelo
  • 687
  • 5
  • 26
  • This has been discussed many time on SO. Take a look at [this](http://stackoverflow.com/questions/647922/java-application-architecture-guide?rq=1) and [this](http://stackoverflow.com/questions/286846/describe-the-architecture-you-use-for-java-web-applications?rq=1) and many more. – techuser soma Mar 15 '13 at 17:29
  • This might be a good topic for [enterprise-architect](http://stackoverflow.com/documentation/enterprise-architect) or [architecture getting started](http://stackoverflow.com/documentation/architecture/7435/). – surfmuggle Oct 31 '16 at 22:14
  • @techuser [Java Application Architecture Guide](http://stackoverflow.com/questions/647922/) or [Describe the architecture for java web applications](http://stackoverflow.com/questions/286846/) seem to be to broad to adress ops question. After reading [best enterprise shopping cart](http://stackoverflow.com/a/6303154/) i thought that looking at open source code e.g. [BroadleafCommerce](https://github.com/BroadleafCommerce) might be a good start to get ideas how to organize code. – surfmuggle Oct 31 '16 at 22:15
  • Does my pseudo-code match what you described? This does not seem to bad to me. How did you solve your refactoring? – surfmuggle Oct 31 '16 at 22:19

1 Answers1

4

For first try to split your application into several layers like:

  • DAO
  • Sevices
  • Security
  • View
  • Etc.

Then extract some API from each of layer (like dao-api, service-api and so on. Each of api modules should have a set of interfaces).

Then create a set of modules (like service-api, service-impl, dao-api, dao-impl) and involve some building tool (gradle or maven) to manage them.

Do not allow one implementation module to have dependency to another implementation module (only impl -> api or api -> api).

Each module - separated jar file.

After such refactoring it will be much harder to break application design in future.

Michail Nikolaev
  • 3,733
  • 22
  • 18
  • Thanks for your answer, i've edited my original question, i hope you can give me some tips on that. – secador de pelo Mar 16 '13 at 15:49
  • if each module will be separed jar files then how about deployment ? – kapil das Nov 12 '13 at 13:11
  • Could you elaborate what you mean by `only implementation -> api or api -> api` does this mean an implementation can be based on several apis (api or api) which are based upon another api? – surfmuggle Oct 31 '16 at 20:33