Event based execution flow and Lucid Features
lezhnev74 opened this issue · comments
I wonder how Lucid architecture describes event based business logic.
How does event handling lays into Lucid paradigm?
For example both CreateNormalAccountFeature and CreateVipAccountFeature create a new account. Let's say, later we decided to have a notification about new accounts. One way is to insert "sendNotificationJob" into each Feature, the other is to hook an event "account_created" and send notification then.
What is your opinion about event based execution?
I see events as part of Domains, and it would be best to have something like Domains/Account/Events/AccountCreatedEvent class.
Here’s a little tip on how I approach figuring out the location of classes:
- The first step of the thought process is discoverability: If I wanted to find this class again after a long time passes, where would I instinctively go to look for it? (hence, Domains)
- Then I think of responsibility: Who’s responsibility is it to hold that functionality? (hence, The specific domain that this event is involved with)
One might eliminate the other, though in no specific priority, depends on which you value most.
A drawback I see with this though, is that if you were to list all the events that would possibly be dispatched by your application, you’d have to go into their corresponding domain to look them up.
Please let me know your thoughts on the above.
Placing events to Domains (like to Domains/Account/Events/AccountCreatedEvent) makes sense and I'd defenitely look for it there.
But the place to put listeners to is something unclear to me.
Listeners should be as public as HTTP routes. Routes declare "doors" to access app via HTTP. Listener maps should declare "doors" to access app via events.
From the top of my head I'd put listeners to Services/<NAME>/Listeners.php since it looks like something specific to a Service. And I'd declare all Domain events I want to handle there. This map can be easily accessed by any developer in the future.
I am thinking about - should "listeners" call Features or Jobs as a reaction to new event?
What's your opinion about that?
Ah, listeners. Yes! definitely part of Services, it is where they belong.
Whether they should call a Feature or a Job is use-case dependent. A Feature is dedicated for what is "exposed" or being discussed as part of the core of the product, but an event occurring is more of a "step" of the Feature.
Unless it is core to the product, I'd have them call a series of Jobs just like a Feature would.
Hi all,
i discovered lucid framework right now, and I find it very interesting.
I'm confused about the listeners.
Why create the Listeners.php files?
What should be in it?
I thought it would be interesting to create the EventServiceProvider.php file (laravel native).
The "subscriptions" in this way could also manage.
What's your opinion about that?
Thanks
@m33ch sounds interesting, can you please give an example of where these files would be and how they would play with the rest of the architecture? i.e. Services/Domains etc.
Hi guys,
I am curious about events as well. Who should be responsible for emitting events a Feature or a Job.
For example I need to create an aggregate entity order with order items, at first I create the order and then items. I have two jobs CreateOrderJob and CreateOrderItemJob. I am running the persisting process in a transaction therefore If I emit an event from a Job it may be invalid in case of the rollback.
I think emitting events from features makes more sense since we may have atomic jobs that can be reused and placing event logic inside a job may lead to create a new job that doesn't emit the event.
What do you think about this matter?
Indeed it makes more sense to fire events from within the features. Unless the job is only responsible for firing that event.
