ORIGAM extensibility libraries as NuGet Packages

ideas
1

We should externalise extensibility interfaces to a NuGet package so development of new extensions gets easier.

Example:

  • Workflow Service Agents base class

UPDATE: ORIGAM Nuget packages are available here.

2

I agree. But we should think through the versioning. Are we going to follow the main product versioning, or is it going to be separated. How much is it going to be integrated in our CI/CD?

3

I think this should live in a separate repository and ORIGAM itself should use it as a NuGet package. IMO it should have its own version starting from 1.0.

4

So we made a basic implementation. It provides a basic interface. Some adapters use some more ORIGAM base functionality though.

Examples:

  • Rule engine’s GetState to ask for a state of a record
  • Reflector class to create multiple instances of other services
  • Accessing OrigamSettings.config
  • Accessing appsettings.json

The best would be to provide those first of all as NuGet packages using dependency injection. But we do not have one.

We could provide e.g. the settings classes as properties until then. Otherwise it will be quite hard to access those files – a lot of duplicate code.

Any ideas how to solve it now in an elegant way?

5

How do you imagine “provide those first of all as NuGet packages using dependency injection”? DI basics say that component declares its dependency needs (best practice tend to be by constructor) and application during the boot up composes the components with needed dependencies (composition root).

I see our current code as an antithesis of DI and I would prefer to spend energy on complete overhaul of the base code to enable DI instead of trying to build a “clean” code on top of it.

For more on the topic I recommend Dependency Injection Principles, Practices, and Patterns.

6

What I mean indeed is that the service adapter would declare its dependencies in the constructor. So e.g. it would require Configuration. In this case it would be a .net core dependency. It could also require something like IRuleEngine (which we do not have) and that would be provided by us as an independent nuget package (not a part of Origam.Service.Core).

What I am describing is not an overhaul of all our code, just a way how to provide dependencies to the workflow services.