Place Incident in comparison to other ES/CQRS libraries

[jonathanstiansen]

Is your feature request related to a problem? Please describe. Jumping on to this library, I'm curious to know how it compares (in design and goals) to Commanded and Fable, as they are the two established solutions in the elixir space.

Describe the solution you'd like For Incident, it'd be great to have a section in the readme describing how the goals of it differ from these other libraries.

For adoption and also development direction, it's likely something that will help people choose incident (if it has a clear different philosophy) instead of other solutions. It's good marketing as well, if we don't know who it's tailored for - we are unable to recommend it.

Describe alternatives you've considered Doing nothing - but I believe this will not encourage people to try incident, or have people recommend incident - since there are already established libraries.

Additional context Thanks for exploring this space and contributing to the community - I'm looking forward to seeing where the project goes 😄

[pedroassumpcao]

Hi @jonathanstiansen, thanks for taking the time, I know that comparison questions are always around in situations like this, and that sometimes having that comparison clear, when possible helps.

In a general way, Incident has one of its goals to be more lightweight and less opinionated if compared with Commanded while I understand that both focus on Event Sourcing AND CQRS aspects. Fable is more more Event Sourcing focused and not so much CQRS. Incident seeks for allowing the developers to have more independence to decide specific things when touching the boundaries between ES/CQRS and other parts of the system (as I understand that systems that use ES/CQRS are not entirely done with it and they are interconnected with other patterns).

Both Commanded and Fable are great options, authored by great engineers so it is hard for me to define what situations someone should use Incident or not, that is a very hard thing to do as each project has so many things involved, most of the times outside the pure software per se that will demand other aspects to be considered as well, such as team members and their experience with ES/CQRS, future goals, if the piece that leverages Event Sourcing/CQRS is a critical component or not, how that portion interacts with other parts of the system, and so on. At the end, comparing isolated solutions alone without considering all the rest becomes not so helpful, unless who is comparing has access to all the other things to evaluate them better.

That's why I preferred add to the Readme what are the goals of Incident and less about all the other options, comparisons and so on. But maybe I can enhance that part of the Readme with much more detailed information about goals and design. What do you think? What specific things would be helpful for you as an example?

[jonathanstiansen]

Hey @pedroassumpcao thanks for the quick response! I think that's fair, and I think that'd be fine instead - but I think that what you've said is a good start.

I think what your saying with the design goals is you'd like it to be more of a toolkit that people can use to build a ES/CQRS solution for their app, instead of framework that forces you into a specific structure - is that what you mean?

I think if you could give a, I hate to say, user story on the framework - "I'm a person needing to build an app, in this context, that has these desires, and I'm going to reach for incident because of ..." would be a good alternative to comparisons.

Or if you can, distill a compelling "why" into a sentence - if you can do it well, it can be great too. To do this I'd usually recommend starting with a reason you gave above, "its light weight" or "non-restrictive", and ask "why does the user care?" and then ask that for each of the next 4 answers to that question (it's the "5 why's" method Toyota coined). It will help distill the product niche down into a very clear thing you are aligning with.