lukaszreszke.bsky.social
Join me on webinar and learn about how to solve typical problems of Rails apps http://products.arkency.com/lessons-from-arkency/
Software Developer @arkency
38 posts
130 followers
261 following
Regular Contributor
Active Commenter
comment in response to
post
However purpose of stream is important too. You probably won't worry about long streams for read models or for debugging purposes.
comment in response to
post
Sorry for late response. I didn't see the notification. I'm wrapping my head around your comments. One thing to keep in mind is to not create streams that are too long. Loading events from long stream might be slow when you reach a certain point.
comment in response to
post
Seems like you could use streams for that instead of additional tables :) There's a video about streams in our youtube channel. Take a look when you have some time, perhaps it'll explain some of my perspective youtu.be/VlSXa5Do_GI
comment in response to
post
@xameyz.bsky.social great post. I noticed that stream is not defined when user events are published. Have you looked into concepts of steams? Extremely helpful when debugging or if you decide to lean more towards event sourcing :)
comment in response to
post
“It's not the responsibility of the model to react to its creation: a model should only be aware of its attributes and its relationships.”
Well said!
comment in response to
post
Interesting! Is it private?
comment in response to
post
Which event store are you using?
comment in response to
post
Agree :) Exceptions from the rule
comment in response to
post
But would be the backend consumed by some frontend client?
comment in response to
post
I would classify it as the first type then :)
comment in response to
post
Tricky one.
I usually start with modeling orchestrated process if I know that at some point it'll have to wait for A and B to happen to do C. Or steps of the procedure need to happen in given sequence.
If thats not the case I'll consider choreography.
Do you follow any rules of thumb/heuristics?
comment in response to
post
www.youtube.com/watch?v=HTjq...
comment in response to
post
So next time you pair program, don't just watch the code - watch the magician's hands 🪄
4/4
#programming #coding #techlife #pairprogramming
comment in response to
post
...make you go "wait, HOW did you do that?!"
The best part? Every dev brings their own flavor.
That Linux wizard you're pairing with? They're basically dropping free masterclasses while you work! 🎓
3/4
comment in response to
post
Pair programming is like getting a backstage pass to someone else's tech habits! 🎭
While your partner is crushing that code review, you might catch them:
- doing some magic in IDE or in VIM with shortcuts you never knew existed
- casually dropping terminal tricks that make you
2/4
comment in response to
post
@ducin.dev dorzuć mnie proszę :)
comment in response to
post
In memory DbContext :)
comment in response to
post
Read more and understand the difference between Turbo Stream, Turbo Frame and Broadcasting turbo streams 👇
blog.arkency.com/the-differen...
#Ruby #RubyOnRails
comment in response to
post
Then all that is left in the aggregate is the knowledge of what to do with the discount. Different use cases call just this one method.
In Event-Driven Architecture there is a benefit for that. Read models subscribe just to one event (DiscountApplied or sth) instead of all possible features
3/3
comment in response to
post
Such pricing-related thing would absorb all the other details such as coupons, time promotions, birthday promotions and so on.
I've done it in similar way in the past.
How do I do it right now?
I delegate those different features/use cases to upper layer
2/3
comment in response to
post
I think it is aligned with Event Modeling's vision. By using PORO* you can quickly experiment and validate design that you need to solve specific business problem. The difference is that it happens in code. Might be better for some devs that stickies
* = any other PO*O <favourite language>