Feedback on Adaptor Design

Premise

From initial glances there appears to be a decent amount of overlap between what a consumer might want to do and what an adapter might want to do. Explore this in more detail to find commonalities and where they diverge in an attempt to develop the basis for adapter grammar.

Guiding questions

• What do consumers share with adapters?

  • consumers and adapters both react to incoming messages, and take some action based on message type and/or contents (on clauses)
  • actions shared between the two include sending of messages (send, publish directives)
  • actions may be conditional, and so constructs such as when and corresponding conditions are necessary

• What do consumers not share with adapters?

  • adapters should not directly manipulate entity state whereas consumers do (set, remove, append directives).

  • consumers are generally consuming and sending messages internal to their context whereas adapters are generally consuming messages from outside the context for translation into the context to which they belong. This has certain implications on message scope.

Do adapters need any capabilities that are not available to consumers? or in the grammar in general as of yet? consumers wrap on clauses by specifying the topic messages belong to as part of the wrapping consumer definition. Adapters will need a similar construct to reference topics/messages originating outside the context - something like this. Such a construct could be used to distinguish context, and whether it applies to CQRS (transforming messages), or other contexts such as REST requests, etc.

Outstanding questions

Should adapters be capable of invoking functions (execute directive) as one of the actions available to them? This depends on what functions are capable of. If functions are capable only of transforming messages into other forms, that would be a valid use case for adapters. If functions are also capable of manipulating entity state within some enclosing context (set, remove, etc), they should not be used within adapters.

Caveats

Adapters cannot always assume they are operating in the context of CQRS. Adapters should also be capable of adapting in other contexts: REST

However, for our purposes, it makes sense to focus on their application in the context of CQRS first and foremost.