Organizing code in Wikibase Lexeme by type/layer so dependencies become clearer, simple guidelines can be created and architectural boundaries can be worked towards more easily.
Initial idea (incomplete and will inevitably be superseded by better understanding as we go along):
src/
Domain/ -- "business code" (no code specific to a single Interactor), probably no MW binding here
Model/ -- DataModel classes, definitely independent from MW
Persistence/ -- Lookups, repositories, etc (interfaces, decorators and trivial implementations) (not sure about the name. Perhaps one folder for Lookups/ and one for Repositories/)
Merge/
Diff/
.../ -- Other coherent sets of domain services
Interactors/ -- "application code" (code specific to a single Interactor), probably no MW binding here
AddLexeme/
MergeLexemes/ -- code specific to the Interactor
MergeLexemeInteractor.php
MergeLexemeRequest.php -- typical structure for new Interactors
MergeLexemeResponse.php -- typical structure for new Interactors. Can also be a MergeLexemePresenter (interface) in case of fractured response model
SupportingApplicationCodeService.php -- cannot be used by anything but the Interactor
.../ -- Other Interactors
DataAccess/ -- persistence implementations (current Store/ folder, perhaps keep that name)
MediaWiki/ -- implementations of MW hook mechanisms
Actions/
Api/
Content/
Specials/
.../ -- Remaining things as they are now, or perhaps organized furtherSome random thoughts related to this structure:
- The DataModel/ folder is no longer called DataModel. This because I think it is good to move away from plain data structures and include domain logic. For instance a TermList can hold to logic to merge in another TermList, rather than having a TermListMergingService. Some things will still warrant a service, and responsibilities such as persistence are definitely best kept in Repositories and the like.
- Current Interactors do not have request and response models. Normally it is good to have these. When there are dedicated Interactor folders you have a more natural place to put these.
- This structure is a step towards being able to strongly separate MW independent code. Ideally the Domain/ and Interactors/ folders do not contain any framework binding.