ordercloud-api/headstart

Rearchitect Middleware Solution

ArchitectedDev opened this issue · 1 comments

ArchitectedDev commented

The current architecture of the middleware solution is difficult to work with

Current Architecture

current-middleware-architecture

Challenges with current architecture

  • Integration projects are strongly coupled to the Headstart.API and Headstart.Common.
  • Unwanted integration projects are complicated to remove from the solution.
  • Integration projects cannot reference headstart models from the Headstart.Common project. The integration-specific code currently resides in the Headstart.API and Headstart.Common projects.

Proposed Architecture

proposed-middleware-architecture

Enhancements with proposed architecture

  • Integration projects can isolate DI, which can then be referenced in the startup of the Headstart.API and Headstart.Jobs, keeping the solution more DRY.
  • Feature-specific controllers and commands will reside in their integration projects.
  • Feature projects can reference headstart models.
  • Headstart.Jobs no longer has a dependency on the Headstart.API project.
  • Added an abstract feature base layer to improve consistency in feature/integration-specific projects.
  • Simplified approach to adding integration projects.
  • Solution can employ helix principles for improved long-term maintenance.

Challenges with proposed architecture

  • Integration specific concrete classes used in headstart model xp would need to be specified in the Headstart.Common (renamed to Foundation.Headstart.Core in the diagram). xp is dynamic, so it is possible to utilise the dynamic class instead of strongly-typed classes.

Other notable proposed changes

  • The OrderCloud.Integration.Library will be split out into integration specific projects, e.g.:
    • Headstart.OrderCloud.Azure.Storage
    • Headstart.OrderCloud.Azure.CosmosDB
    • Headstart.OrderCloud.Taxation
  • Headstart.Common is changed to Foundation.Headstart.Core to provide a little better context and dissuade developers from using the project as a catch all bucket.
  • The Headstart.API and Headstart.Common projects will have features/integrations broken out into their own specific projects.
  • The following namespace naming convention will adopted <Company>.<Product>[.<Feature>][.<Subnamespace>]
    • 'Integration' is dropped from the namespace with context derived from the <Subnamespace>
    • <Company> being 'Headstart' would be swapped out for client company as part of solution getting started guide.
ajsuth commented

Closing this as primary objectives have been acheived and ongoing refactoring will continue.