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 further
Some 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.