Design Recommendations

Since we are just discovering the interplay between StreamIds and related factories and pros and cons of different patterns, it seems to be in order to start writing down some observations and the actual state of knowledge:

derived stream ids

While at a first glance it looks very tempting to solve many problems through derived stream ids, it can come with one big disadvantage: A derived stream id always exposes an additional (lower) layer to the client. While this is in some cases unproblematic, it can give big problems in other cases. Particular problematic are cases where the lower layer introduces additional dependencies, which otherwise would not be required by the client.

We should think of stream ids as client domain objects. They should be easy to construct and/or be provided in a catalog of constants (could be generated). In general it should be avoided that the client has to know more than absolutely necessary to discover a stream.

On the other hand, embedding logic in stream ids makes a lot of sense in other cases: For example it is the basis for the whole online-analysis concept. In this case it is particularly wanted that logic is defined by the client.

Streaming pool extension libraries

While at the moment, streaming pool extensions usually provide both, stream ids and corresponding factories in one library, it could make sense to split this soon into two: Something like 'streaming-pool-ext-xxx-domain' and 'streaming-pool-ext-xxx-backend'. The domain part would then contain the stream ids and additional domain objects (if required). The backend part would contain the logic and potentially required additional dependencies. While such a split makes no difference in the current approach (embedded), it will make a big one as soon as we have 2-tier mode: Then a client would only depend on the domain part and streaming-pool-core-client (which also will have to be split out from core).