Page Comparison

...

common
domain-dto
testFramework
serviceInterfaces
userInterfacesuserInterface
accounting
questionnaire
cashflow
abstract-domain
organization
appdomain
application

common

project dependencies: NONE
produces a JAR file
should contain cross functional infrastructure utilities
- That said, can become a bit of a bucket, throw it in common so module x and y will have access to it....
- could probably be split up further, common-date, common-infrastructure etc

domain-dto

project dependencies: NONE
produces a JAR file
should contain DTO classes that referenced in domain entitiy classes
- e.g. didn't want organisaztion module depending on serviceInterfaces module (where all dtos are currently)

testFramework

project dependencies: common
produces a JAR file

serviceInterfaces

project dependencies: common, domain-dto
produces a JAR file
contains interface definitions of all/most service facades (application services) and DTO classes used in service facade signature.
Key point is that there is no knowledge of any domain concepts
Introduce as architectural check to ensure now domain concepts leaking into inteface of services and as such leaking into UI.

QUESTION from Vivek: not used anymore? if not then what would it have?

Answer from Keith: At present, this is very much used.

userInterface

project dependencies: common, serviceInterfaces
produces a JAR file
contains freemarker and spring mvc/spring webflow controllers and related UI beans used in user interface
Key point is that there is no knowledge of any domain concepts and interacts only with layer below serviceInterfaces (service facades or application services)

accounting

project dependencies: common
produces a JAR file
Let Udai describe this in more detail

questionnaire

project dependencies: serviceInterfaces (but only to reference questionnaire specific DTOs)
produces a JAR file

cashflow

project dependencies: common, serviceInterfaces (but only to reference questionnaire specific DTOs)
produces a JAR file

abstract-domain

project dependencies: common, domain-dto
produces a JAR file
Purpose is really for core domain abstractions that other modules classes depend on

QUESTION from Vivek: it has country, language etc. given that it shouldn't be called abstract-domain. these are reference and configuration data. It also contains cross module domain related things, which seems to be fine.

Answer from Keith: yes your right at present it has classes that are not really 'abstract' concepts and yes some of these are 'reference-data' or 'master-data' classes which can be pulled out into another module called 'reference-data' or whatever. I just didn't go that far in this piece of work.

organization

project dependencies: common, domain-dto, abstract-domain
produces a JAR file
at present contains organization related domain entities, holiday, office, personnel (not their DAOs or domain services etc)

appdomain

project dependencies: all projects except for application
produces a JAR file

QUESTION from Vivek: only service facades?

Answer from Keith: no, this is purely a slightly less monolithic module than the previous 'application' one and at present should contain everything needed to implement service interfaces through code in this module or through required dependencies on other modules

application

project dependencies: all projects
produces a WAR file