Domain Services
DomainService is a domain oriented construct, which does all particular operations related to one-and-only-one domain concept. NOTE: TBD - do we alternatively use this as repository instead?
- Or even invert such that a DomainService is injected onto entities (like current BOs, but using @configureable with AOP load-time weaving/or build time weaving using mvn+AspectJ. Not sure how Hibernate cached entities would behave in such scenarios!
candidates: Any <X>BO.
for example FeeBO.
In reality, mifos codebase has mixed up BOs (Business Objects) with BusinessService. Such code bases should be merged (not in legacy code) to represent one single Domain Service. Many such legacy BusinessServices do not actually persist, rather most of the time use to retrieve related info persistence. e.g. FeeBusinessService
It is more likely that an entity would not demand change in representation, but is expected to go behavioral change for a business process.
note Spike code has a domain service called FeeService. This was created to separate out the persistence from FeeBO.
@Override public FeeEntity updateFee(UserContext userContext, Short feeId, Money feeMoney, Double rate, FeeStatus feeStatus) throws PersistenceException { FeeEntity fee = feeDao.getDetails(feeId); FeeChangeType feeChangeType; if (fee instanceof AmountFeeEntity) { AmountFeeEntity amountFee = (AmountFeeEntity) fee; feeChangeType = amountFee.calculateChangeType(feeMoney, feeStatus); amountFee.setFeeAmount(feeMoney); } else { RateFeeEntity rateFee = (RateFeeEntity) fee; feeChangeType = rateFee.calculateChangeType(rate, feeStatus); rateFee.setRate(rate); } fee.setFeeStatus(retrieveFeeStatusEntity(feeStatus, userContext.getLocaleId())); fee.updateFeeChangeType(feeChangeType); fee.setUpdatedDate(new [DateTimeService]().getCurrentJavaDateTime()); fee.setUpdatedBy(userContext.getId()); feeDao.update(fee); return fee; }
(These were pulled out of Action classes) Do we code to righteous DDD? This is a big question that will need to be decided for establishing the domain layer pattern. ref: http://martinfowler.com/bliki/AnemicDomainModel.html
TODO: More to add.