As discovered in the thread, I wasn’t quite looking at Ash PaperTrail itself … rather it was a different paper trail.
But since I went with carbonite, I didn’t have a need to immediately re-evaluate Ash PaperTrail.
I would definitely look at Ash Paper Trail again if I had a need in a new project. But also, at that future time, I would also take a look at Ash Events – per zach.
Longer answer
And it would depend on the problem statement to solve. I could see different needs depending on the situation.
- Is “versioning the resource” a first class concept for the feature, and exposed to the user? For example, a user may want to rollback/forward different draft versions of an Article?
- Ash Paper Trail w/ version may look promising here
- Or is it a non-functional issue like auditing?
- I’ll want to re-evaluate the experience with carbonite at that time, see what worked or didn’t work.
- Or how much we may need, or not need, “Event Driven Architecture”…
- “Event Driven Notification” and/or “Event-State Carried Transfer” needed?
- Do we want to keep resource state using “Event Sourcing” (Ash Events or Commanded)?
- Would there be a path to use Event Sourcing, translate that State Event to a Domain (or Integration) Event for publication to Domain or other “Bounded Contexts”?
- Would the problem even be complicated enough to need all the extra work/complexity for DDD and these kinds of Tactical Patterns?
Summary
But sorry 
, @terris , I don’t have any thoughts on Ash PaperTrail for you at this moment-- maybe in the future.
