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 api and impl
| |
| 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 asdress '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 are can be shared between given features and are NOT exposed on any API | |
| 10 | utils | all implementation classes that can be shared between features | |
| 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