Architecture Concerns

My domain classes and persistance logic (Hibernate) are in one project called model. This jar is included within all of my apps.

Packaged com.company.model & com.company.persistance

Another Utils.jar - contains DateTime, String, Thread, etc general helper classes. This again is included within all of my apps.

Packaged com.company.utils

I have a CXF/Spring app that exposes services for manipulating my data. CRUD functionality, ALL other common functions. This is the 'way in' to my database for any app designed.

Packaged com.company.services and running on Glassfish app server

I have other apps that use the web services (Spring injected) to manipulate my data. Including a web app that will use YUI widgets and the XML/JSON from the web services for a nice smooth UI.

I understand its not really a question! I suppose Im looking for confirmation that this is how others are designing their software. If my architecture makes good, logical sense! Obviously there are security concerns - I wil开发者_高级运维l want some applications allowed to only access service x. I will address these later.

Sounds good.

It depends also of the type of application you're developing and the specific requirements for that ( it has to be deployed every week, it has to be deployed in several locations etc )

But so far sounds good enough.

Looks like you can formulate a question from here in the future for some specific scenario.

Since this is not a question, mine is not really an answer. CW

My only comment would be to put the persistence and Hibernate classes into a separate module; so that the model module can be purely beans/POJO/your domain classes.

Here's how I've organized a few multi-module projects before

• project-data - contains domain classes and DAOs (interfaces only)
• project-services - "Business logic" layer services, makes use of DAO interfaces.
  • Depends on project-data.
• project-hibernate - Hibernate implementation of DAO interfaces.
  • Depends on project-data.

Conceivably if I were to use some other sort of data-access method I would just create a separate module for that. Client apps could then choose which modules to be dependent on.

Only suggestion I might have is that when you're creating service/models that you group them by subpackage name. ie

com.company.model.core com.company.service.core

com.company.model.billing com.company.service.billing

Also, be careful to ensure that no controller code (manipulating your UI) ends up in the services.