TECHDEBT: layering: Remove persistence usage from GroupBO

Description

This is part of technical debt work to isolate the domain model.

GroupBO

Pros:
#. static factory methods in place and used by application code
#. Builder exists for creation of GroupBO

Cons:
#. extends customer (too much behaviour leaked into customer from other sub classes group/client that is not relevant)
#. deprecated constructors still exists but only used by test infrastructure.

  • as a result, there is good deal of code used only from deprecated constructors..

Notes:

#. Group can be created in lots of states.
#. customer account always created with group (i presume to handle attachment of fees etc)
#. only behaviour seems to be updatePerformaceHistoryOnXXX, validation and behaviour around checking states

other tidy up for group

  • segregated interface should be used instead of empty methods on base class

  • see all updatePerformanceHistoryOnXXXEvent, empty methods on base class are over-ridden, only relevant cause loans are allowed for groups, as a result see that GroupPerformanceHistoryEntity breaks layering rules and uses services/daos to fetch neccessary data.

This story is about removing persistence responsibilities from GroupB which involves:

  • remove GroupBOIntegrationTest and have only unit tests around GroupBO

  • remove use of deprecated GroupBO constructors used only in integration tests and other code only invoked from deprecated constructors

  • requires tidy up of where TestObjectFactory.createGroup is used

  • replace with use of Builder + IntegrationTestObjectMother.createCenter(XXX)

Environment

None

Assignee

mifosdeveloperqueue

Reporter

keithwoodlock

Labels

Implementation Priority

None

URL

None

Story Points

4

Team

Core

Scheduled For

Product

Epic

None

productboard URL

None

Man Day Estimate

None

Components

Fix versions

Priority

Trivial
Configure