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!!!
2
use feature based packages
Team agreed to use the current 4
service
services (or 5 depending on inventory) as feature folders directly under impl and some also under api
and impl
datajobs
The following feature structure emerged during the actual refactoring
cmsubscriptions
cmhandlequeries
(TBC)
proxydataservice (TBC passtrough data services)
cacheddataservice(TBC cached data services)
data
async
datajobs
inventory
sync
lcm
trustlevel
inventory (TBC)
3
when to use common packages
when in doubt use common package ie exceptions might be re-used for
otrerh
other features in
teh futures
the future
4
scope
curerntly
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
adress
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
