Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

References

CPS-2240 - Getting issue details... STATUS

Issues & Decisions


IssueNotes Decision
1use api and impl folders

Team agreed on separate top level ap and impl folders. Common impl folders can be at top level ie. not under impl.
any class in api should not depend (i.e. nor import) anything from impl or common folders!!!  

2use feature based packages

Team agreed to use the current 4 services (or 5 depending on inventory)  as feature folders directly under api and impl

  • datajobs
  • cmhandlequeries (TBC)
  • proxydataservice (TBC passtrough data services)
  • cacheddataservice(TBC cached data services)
  • inventory (TBC)
3when to use common packages

when in doubt use common package ie exceptions might be re-used for other features in the future

4scope

currently only ncmp-service in scope. 

5plan

team agreed to do trial with 'datajobs' first. Code need to be reviewed by both teams. Once this is completed we will asdress 'legacy' services

Proposed Generic Structure


PackageScopeNotes
1apiall classes that are required for northbound interfaces
2api\featureall API classes that are specific to a given feature
3api\feature\modelsall data-holder type classes for the API specific to the featuredo NOT add data objects that are only used in the impl!
4api\feature\exceptionsall exception classes that are specific to a given featuredo think 'ahead': is the exception rally going to be unique for this feature! 
If in doubt it probably should go into api\exception. Because moving it later would be a backward incompatible change!
5api\modelsall data-holder type classes for the API that can be shared between features
6api\feature\exceptionsall exception classes that can be shared between features and at least oen feature exposes on the API
7implall classes that are NOT exposed on the northbound interface and are unique to just one featuresince these classes are NOT exposed on the API it is OK to move them to the common utils\ package only when needed (i.e. later) since this would not be backward incompatible
8api\featureall implementation classes that are specific to a given feature
9exceptionsall exception classes that are can be shared between given features and are NOT exposed on any API
10utilsall  implementation classes that can be shared between features


Generic folder (package structure)
api\feature1\SomeService.class
api\feature1\models\SpecificModelClass
api\feature1\exceptions\SpecificException.class
api\feature2\SomeService.class
api\feature2\models\SpecificModelclass
api\feature2\exceptions\SpecificException.class
api\models\CommonModel.class
api\exeptions\CommonException.class

impl\feature1\SomeServiceImpl.class
impl\feature1\helperPackage\SpecificHelper.class
impl\feature2\SomeServiceImpl.class

exceptions\someInternalException.class
utils\CommonHelper.class


Proposed DataJobs Structure

Proposed structure (not complete but indicative):

datajobs
api\datajobs\DataJobsService.class
api\datajobs\models\DataJobMetadata.class
api\datajobs\models\DataJobReadRequest.class
api\datajobs\models\DataJobWriteRequest.class

impl\datajobs\DataJobsServiceImpl.class

exceptions\NoAlternateIdParentFoundException.class
utils\AlternateIdMatcher.class
  • No labels