Ruby, JavaScript
Hi, we're Arkency and it's our blog with meaty content.
A question has been posted on our Arkency's slack today: How to rename stream in event store? Is link & delete_stream enough to do it? Asking for a friend ;) At first it looks quite easy. Sure, we can! Just link add events from source stream to target stream, then change publisher to write to new stream and use delete_stream method of Rails Event Store to remove old stream. Ahhh, and of course we must handle incoming domain events, with zero downtime. And now where the fun begins :)
Hi, we're Arkency and it's our blog with meaty content.
The usual way of handling domain events in Rails Event Store is using the included pub-sub mechanism. And in most cases, especially when you have majestic monolith application it is enough. It is also easiest to grasp by the team and use in legacy applications implemented using Rails Way. But sometimes it is not enough, sometimes this way of handling events become an obstacle.
Today I would like to talk about how to work remotely and how we do it at Arkency. We’re living in crazy times right now, almost everyone seems to be working remotely, so I thought it would be a good idea to share some experiences we’ve had with remote (and asynchronous) work since we first started working like this around 15 years ago. I think some of the ideas I’m going to share are universal and can be applied to any profession, not just programming or software development. It is interesting to see how well the whole concept of remote work seems to be doing right now that everyone is embracing it. For some people, it’s a completely novel approach to going about their work, while others have been practicing it for some time. But even within one team, there can be people who have and who haven’t done it, which, of course, may create some difficulties.
Speaking of connections in Active Record, there are three things you may deal with: Connection Connection pool Connection handler Here's how they relate to each other.
Hi, we're Arkency and it's our blog with meaty content.
Being remote means you not always have a face to face contact with your customers, with the domain experts or with the right people who know you the business you try to model works. This must not be an excuse to skip the modeling part. It is even more important to have a good shared understanding of the domain and the problem you try to solve, to build & use the ubiquitous language.
If you ever wondered how to make 3rd party API call from Aggregate and not clutter it with dependencies, you may find this post interesting.
How to migrate legacy Rails apps into DDD/CQRS in a relatively safe way?
This is the story how we once migrated an in-house event store, that reached its limits, to Rails Event Store.