search

lawrencegripper / ion

MIT License
12 stars 6 forks source link

Proposal: expand Ion metaphor for domain modelling #64

Open jjcollinge opened 6 years ago

jjcollinge commented 6 years ago

I'm just documenting a proposal to discuss later:

The reason the system is called Ion is based on the following metaphor: A molecule consisting of 2 atoms (a module and a sidecar) emits electrons (events). The electrons are pulled into other atoms in another molecule via a bond (dispatcher). Atoms can also radiate photons (insights) sporadically. A graph of these molecules is called a compound. This metaphor is based on ionic bonding between molecules/atoms.

Some systems choose to use the metaphor as a basis for model the code,. If we opted to do so we could make the following changes: event => electron job => molecule module => atom workflow => compound publish(event) => emit(electron) dispatcher => binder dispatch(job) => bind(molecule) insight => photon

Or we use generic naming as we have done this far and leave the metaphor implicit. I know this isn't functionally important but helps build the brand and a mental model for the system. Note, all metaphors break down at some point and this can also cause confusion.

Open to thoughts?

lawrencegripper commented 6 years ago

So I've been thinking about this since the weekend and I'm really split. Orleans took a similar approach with grains and silos mapping to the world of farming.

The issue I struggle with is the metaphor isn't of any use unless you have an understanding of the domain it came from. For those with a physics background this would likely provide a useful guide but with my non-physics background it doesn't help much.

That being said it does clearly stop the use of overloaded terms like job or event from becoming muddled due to the unique nature of the metaphor. This could be a great benefit as users don't carry over preconceptions about the behavior or use of an overloaded term.

The downside of this is it makes the framework less approachable as most users expectations of an event do map to how we behave, by naming it something else this understanding isn't immediately useful.

So in summary I'm conflicted.