One potential issue with this pattern is that the knowledge of which implementation should be used appears to be encoded in more than one place. That is, there appears to be a 1:1 mapping between an externally exposed concept (ProcessingType), and the implementation of each type.

This fact suggests a question: if the internal implementations should be hidden, then why does the caller know about each individual one by name, and if the internal implementations shouldn't be hidden, why not just expose those as part of the exercisable API?

That I'm asking these questions don't guarantee that anything is actually awry. If the code in question is functioning as a kind of "seam-crosser" that translates an external grammar into an internal/domain ubiquitous language, and it is merely a possibly-temporary coincidence that these are the same terms (for now), then this may be perfectly well justified.

On the other hand, some clear and deliberate thinking on which of the various interoperating pieces & systems should know various aspects of the full problem and entire distributed system could yield some valuable insight.

Perhaps these additional questions might help you zero in on what you are trying to accomplish:

1. Should the caller actually know about confabulation, reticulation, and splicing? Or should it just submit some data and let the callee decide? Is it effectively handing in nouns, or does it really want to use verbs? Who's the authority, here? What creates value to have the decider of which action separate from the implementer of each action?

2. Where are changes mostly likely to occur in this scheme, and which changes are likely to occur at the same rate, in the same areas? Have you designed things so that any single reason for the system to change is likely to affect only one, or very few, code modules? Could the internal implementation increase from three verbs into five or six with the outside caller remaining ignorant of this? Is the problem space or domain of the callee distinct enough from the problem space of the caller that adopting the caller's terms could end up improperly distorting the organization of and concepts within the internal domain?

3. When you think about the different aspects of actions that must be carried out, and the different parts of your system, can you identify any clear delineations about which part of the system should know each aspect? For example, these aspects don't automatically have to be co-located: when an action should happen, what action should happen and in which cases, which part actually triggers an action happening, which part knows how to carry out an action, which part knows the answers to all of these questions and connects them so they coordinate properly, and so on. But however close or far these things are, each does represent a single reason that code might change—suggesting they should at least be individual functions, if not promoted to classes or even entire libraries or separate systems.

Asking these question is not creating complexity. Asking these questions is discovering inherent complexity and then aligning code to the real world to achieve the lowest functional complexity over time: the fewest bugs, the least amount of failures, code that is the easiest to understand, the easiest to change or extend, the easiest to test, with the least amount of technical debt.

In my book, adequately addressing real-world complexity in order to achieve these "easies" is actually reducing complexity overall.

One potential issue with this pattern is that the knowledge of which implementation should be used appears to be encoded in more than one place. That is, there appears to be a 1:1 mapping between an externally exposed concept (ProcessingType), and the implementation of each type.

This fact suggests a question: if the internal implementations should be hidden, then why does the caller know about each individual one by name, and if the internal implementations shouldn't be hidden, why not just expose those as part of the exercisable API?

That I'm asking these questions doesn't guarantee that anything is actually awry. If the code in question is functioning as a kind of "seam-crosser" that translates an external grammar into an internal/domain ubiquitous language, and it is merely a possibly-temporary coincidence that these are the same terms (for now), then this may be perfectly well justified. (It is less likely to be justified, though, if the use case is simply one piece of code calling another piece of code, and there's no serialization occurring such as in a web service, and no translation happening such as in handling a text-based CLI command.)

On the other hand, some clear and deliberate thinking on which of the various interoperating pieces & systems should know various aspects of the full problem and entire distributed system could yield some valuable insight.

Perhaps these additional questions might help you zero in on what you are trying to accomplish:

1. Should the caller actually know about confabulation, reticulation, and splicing? Or should it just submit some data and let the callee decide? Is it effectively handing in nouns, or does it really want to use verbs? Who's the authority, here? What creates value to have the decider of which action separate from the implementer of each action?

2. Where are changes mostly likely to occur in this scheme, and which changes are likely to occur at the same rate, in the same areas? Have you designed things so that any single reason for the system to change is likely to affect only one, or very few, code modules? Could the internal implementation increase from three verbs into five or six with the outside caller remaining ignorant of this? Is the problem space or domain of the callee distinct enough from the problem space of the caller that adopting the caller's terms could end up improperly distorting the organization of and concepts within the internal domain?

3. When you think about the different aspects of actions that must be carried out, and the different parts of your system, can you identify any clear delineations about which part of the system should know each aspect? For example, these aspects don't automatically have to be co-located: when an action should happen, what action should happen and in which cases, which part actually triggers an action happening, which part knows how to carry out an action, which part knows the answers to all of these questions and connects them so they coordinate properly, and so on. But however close or far these things are, each does represent a single reason that code might change—suggesting they should at least be individual functions, if not promoted to classes or even entire libraries or separate systems.

Asking these question is not creating complexity. Asking these questions is discovering inherent complexity and then aligning code to the real world to achieve the lowest functional complexity over time: the fewest bugs, the least amount of failures, code that is the easiest to understand, the easiest to change or extend, the easiest to test, with the least amount of technical debt.

In my book, adequately addressing real-world complexity in order to achieve these "easies" is actually reducing complexity overall.

One potential issue with this pattern is that the knowledge of which implementation should be used appears to be encoded in more than one place. That is, there appears to be a 1:1 mapping between an externally exposed concept (ProcessingType), and the implementation of each type.

This fact suggests a question: if the internal implementations should be hidden, then why does the caller know about each individual one by name, and if the internal implementations shouldn't be hidden, why not just expose those as part of the exercisable API?

That I'm asking these questions don't guarantee that anything is actually awry. If the code in question is functioning as a kind of "seam-crosser" that translates an external grammar into an internal/domain ubiquitous language, and it is merely a possibly-temporary coincidence that these are the same terms (for now), then this may be perfectly well justified.

On the other hand, some clear and deliberate thinking on which of the various interoperating pieces & systems should know various aspects of the full problem and entire distributed system could yield some valuable insight.

Perhaps these additional questions might help you zero in on what you are trying to accomplish:

1. Should the caller actually know about confabulation, reticulation, and splicing? Or should it just submit some data and let the callee decide? Is it effectively handing in nouns, or does it really want to use verbs? Who's the authority, here? What creates value to have the decider of which action separate from the implementer of each action?

2. Where are changes mostly likely to occur in this scheme, and which changes are likely to occur at the same rate, in the same areas? Have you designed things so that any single reason for the system to change is likely to affect only one, or very few, code modules? Could the internal implementation split into 5 or 6, while the outside caller remains ignorant of this? Is the problem space or domain of the callee distinct enough from the problem space of the caller that adopting the caller's terms could end up improperly distorting the organization of and concepts within the internal domain?

3. When you think about the different aspects of actions that must be carried out, and the different parts of your system, can you identify any clear delineations about which part of the system should know each aspect? For example, these aspects don't automatically have to be co-located: when an action should happen, what action should happen and in which cases, which part actually triggers an action happening, which part knows how to carry out an action, which part knows the answers to all of these questions and connects them so they coordinate properly, and so on. But however close or far these things are, each does represent a single reason that code might change—suggesting they should at least be individual functions, if not promoted to classes or even entire libraries or separate systems.

Asking these question is not creating complexity. Asking these questions is discovering inherent complexity and then aligning code to the real world to achieve the lowest functional complexity over time: the fewest bugs, the least amount of failures, code that is the easiest to understand, the easiest to change or extend, the easiest to test, with the least amount of technical debt.

In my book, adequately addressing real-world complexity in order to achieve these "easies" is actually reducing complexity overall.

One potential issue with this pattern is that the knowledge of which implementation should be used appears to be encoded in more than one place. That is, there appears to be a 1:1 mapping between an externally exposed concept (ProcessingType), and the implementation of each type.

This fact suggests a question: if the internal implementations should be hidden, then why does the caller know about each individual one by name, and if the internal implementations shouldn't be hidden, why not just expose those as part of the exercisable API?

That I'm asking these questions don't guarantee that anything is actually awry. If the code in question is functioning as a kind of "seam-crosser" that translates an external grammar into an internal/domain ubiquitous language, and it is merely a possibly-temporary coincidence that these are the same terms (for now), then this may be perfectly well justified.

On the other hand, some clear and deliberate thinking on which of the various interoperating pieces & systems should know various aspects of the full problem and entire distributed system could yield some valuable insight.

Perhaps these additional questions might help you zero in on what you are trying to accomplish:

1. Should the caller actually know about confabulation, reticulation, and splicing? Or should it just submit some data and let the callee decide? Is it effectively handing in nouns, or does it really want to use verbs? Who's the authority, here? What creates value to have the decider of which action separate from the implementer of each action?

2. Where are changes mostly likely to occur in this scheme, and which changes are likely to occur at the same rate, in the same areas? Have you designed things so that any single reason for the system to change is likely to affect only one, or very few, code modules? Could the internal implementation increase from three verbs into five or six with the outside caller remaining ignorant of this? Is the problem space or domain of the callee distinct enough from the problem space of the caller that adopting the caller's terms could end up improperly distorting the organization of and concepts within the internal domain?

3. When you think about the different aspects of actions that must be carried out, and the different parts of your system, can you identify any clear delineations about which part of the system should know each aspect? For example, these aspects don't automatically have to be co-located: when an action should happen, what action should happen and in which cases, which part actually triggers an action happening, which part knows how to carry out an action, which part knows the answers to all of these questions and connects them so they coordinate properly, and so on. But however close or far these things are, each does represent a single reason that code might change—suggesting they should at least be individual functions, if not promoted to classes or even entire libraries or separate systems.

Asking these question is not creating complexity. Asking these questions is discovering inherent complexity and then aligning code to the real world to achieve the lowest functional complexity over time: the fewest bugs, the least amount of failures, code that is the easiest to understand, the easiest to change or extend, the easiest to test, with the least amount of technical debt.

In my book, adequately addressing real-world complexity in order to achieve these "easies" is actually reducing complexity overall.