References
CPS-2240 - Getting issue details... STATUS
Issues & Decisions
| Issue | Notes | Decision | |
|---|---|---|---|
| 1 | use 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. | |
| 2 | use feature based packages | Team agreed to use the current 4 services (or 5 depending on inventory) as feature folders directly under impl and some also under api The following feature structure emerged during the actual refactoring
| |
| 3 | when to use common packages | when in doubt use common package ie exceptions might be re-used for other features in the future | |
| 4 | scope | currently only ncmp-service in scope. | |
| 5 | plan | team agreed to do trial with 'datajobs' first. Code need to be reviewed by both teams. Once this is completed we will address 'legacy' services |
Proposed Generic Structure
| Package | Scope | Notes | |
|---|---|---|---|
| 1 | api | all classes that are required for northbound interfaces | classes that are directly used by the REST interface (or controllers) |
| 2 | api\feature | all API classes that are specific to a given feature | |
| 3 | api\feature\models | all data-holder type classes for the API specific to the feature | do NOT add data objects that are only used in the impl! |
| 4 | api\feature\exceptions | all exception classes that are specific to a given feature | do 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! |
| 5 | api\models | all data-holder type classes for the API that can be shared between features | |
| 6 | api\feature\exceptions | all exception classes that can be shared between features and at least oen feature exposes on the API | |
| 7 | impl | all classes that are NOT exposed on the northbound interface and are unique to just one feature | since 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 |
| 8 | impl\feature | all implementation classes that are specific to a given feature | a feature could be NOT direct used by a API feature but maybe api features can depend on a common implementation feature such as 'trustlevel' or 'sync/data' and 'sync/module' |
| 9 | exceptions | all exception classes that can be shared between given features and are NOT exposed on any API | |
| 10 | utils | all implementation classes that can be shared between features but don't belong to a specific feature | even if classes are used by several API feature that doesn't mean thry have to go here. They can stull be part of a common (impl. only) feature e.g. TrustLevel |
| 11 | models | all data-holder type classes used in impl only that can be shared between features |
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):
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