The top-level system architecture can be depicted using the following diagram:
Let's walk through these modules briefly.
This part is a set of low-level tools used by all modules except Model. Includes:
- Data processor registry implementation. Allows to associate particular business logic with the arbitrary class' hierarchy. Client of the data processors registry retrieves appropriate data processor by calling getProcessor factory method and specifying the target class. This tool сan be considered as the more robust replacement of the Visitor design pattern.
- Data set abstraction. Ties data retrieving and set count logic together in one class.
Data Model represents a set of the persistent entities managed by the Hibernate framework. This module have no dependencies on others. See details on how entites related with each other here.
Data Access Objects (DAO) are means for access and manipulation with the persistent entities of the Model module. Typical DAO is just a set of the problem-oriented operations related to the single, particular entity. For example, take a look at the ContractDAO. DAOs are simple objects just perform simple manipulation with persistent data according specified parameters.
Core module built on top of the Model and DAO and contains set of services implementing the main business logic including:
- User maintenance (registration, reputation management, skills providing) located in package org.zeroexchange.user
- Collaboration maintenance (whole collective contract lifecycle support) in org.zeroexchange.collaboration package
- Value (including classic money) management
- Events dispathing (delivering contract lifecycle events to the interested components) in org.zeroexchange.event
- Messaging (sending emails and maintaing of private user messages) in org.zeroexchange.messaging
Core module also introduces a number of the following abstractions to implement separation-of-concerns principle:
- Readers services provide means for retrieving the business data objects. Unlike DAOs, readers are not tied to the single entity. They can use number of entities, implement complex business logic and provide fine-grained access to the particular kind of information. See CategoryReader for example.
- Writers are like Readers but intended to write, persist information.
- Informants are special case of readers providing requred information using complex calculations. For example, ContractInformant's getCreditors method collects contract's users by walking through the contract's effective users and checking user's balance in the contract's scope.
User interface is a set of Wicket-based web pages that allow human to use core system's functionality. UI module exploits Core and Model modules.
Intended to provide interface to the access core functionality via SOAP-based web services exposed via Apache CXF. This module is in the early development and not very useful at the moment.