This issue is probably going be resolved in the same branch as #26, but I felt like it was significant enough to be its own issue.
At present, the Core.Logic project directly references Core. However, with #26 I'm exposing more and more public interfaces for reference by the host that I'd really rather that the business logic layer not be aware of. IJobSource being public since forever probably should have been enough of a reason to do this ages ago, but here we are.
Anyhow, to resolve this I'd like to draw a border for stuff that I'd rather the business logic layer now be aware of.
Plan:
- Declare a new project called
RedShirt.Example.JobWorker.Common.
Common shall reference no projects. This is the ground floor.Common shall be directly referenced by Core and Core.Logic- All public constructs that I want the business logic layer to be aware of go here
- Some off-the-cuff examples:
IJobModelIJobDataModelJobResult enumIJobLogicRunnerISleepService
This concern about inheritance borders also kind of exists between the JobManagement projects with their job source implementations, but I'm less concerned about them because they're more established compared with Core.Logic's barebones template setup.
At the end of the day, anyone using this template is certainly capable of being responsible with how they handle their application design. There's nothing stopping someone implementing this template from referencing Core themselves or making even more constructs public. However, I can still use these library borders to discourage that bad idea and maybe make auto-complete a bit less crowded.
This issue is probably going be resolved in the same branch as #26, but I felt like it was significant enough to be its own issue.
At present, the Core.Logic project directly references Core. However, with #26 I'm exposing more and more public interfaces for reference by the host that I'd really rather that the business logic layer not be aware of.
IJobSourcebeing public since forever probably should have been enough of a reason to do this ages ago, but here we are.Anyhow, to resolve this I'd like to draw a border for stuff that I'd rather the business logic layer now be aware of.
Plan:
RedShirt.Example.JobWorker.Common.Commonshall reference no projects. This is the ground floor.Commonshall be directly referenced byCoreandCore.LogicIJobModelIJobDataModelJobResultenumIJobLogicRunnerISleepServiceThis concern about inheritance borders also kind of exists between the
JobManagementprojects with their job source implementations, but I'm less concerned about them because they're more established compared withCore.Logic's barebones template setup.At the end of the day, anyone using this template is certainly capable of being responsible with how they handle their application design. There's nothing stopping someone implementing this template from referencing Core themselves or making even more constructs public. However, I can still use these library borders to discourage that bad idea and maybe make auto-complete a bit less crowded.