mmmoli commented 6 months ago

Playing with the new TsEvent api.

Looks like it supersedes your finance-app example.

Any tips for how to make subscriptions with the new API?

Thanks!

4lessandrodev commented 6 months ago

Hey @mmmoli , thanks for reaching out! Since the "finance project", the library has undergone several upgrades, particularly in event handling. Take a look at the new approach for the eventHandler in this example. There are various ways to add an event to the aggregate, but instead of dealing with global events, I suggest utilizing events directly within the aggregate instance. Check out this example to see how to add an event to an aggregate instance.

I hope this clears things up a bit. Feel free to ask if you have any further questions.

mmmoli commented 6 months ago

Buddy, I've studied your examples at length… 👀😄

They've been a huge help.

I'm looking for advice for subscribing to these Domain Events within a different bounded context/module. Hoping to set-up a "pull" mechanism rather than "push"

Do I need to add an external event Bus? Should I dispatch these event inside the dispatch of the Event handler? 🙃

4lessandrodev commented 6 months ago

Absolutely, glad to hear the examples have been helpful!

For subscribing to Domain Events across different bounded contexts/modules with a "pull" mechanism, you typically need to establish communication between these contexts.

For handling events across different modules with a "pull" mechanism, consider leveraging the Node.js Event emitter. Similar to how events are handled in browser-based JavaScript, Node.js offers the EventEmitter class within its events module.

4lessandrodev commented 6 months ago

Testing something new

@mmmoli Your question made me think a lot about the need for a tool that facilitates communication between contexts. Currently, the way it is structured, it is not possible to meet this requirement. That's why I'm thinking about implementing something similar to the draft below


import { Aggregate, Ok, Result, Context } from "rich-domain";

type Props = { name: string };

class User extends Aggregate<Props>{
    private constructor(props: Props) {
        super(props);
    }

    public static signUp(name: string): User {
        return new User({ name });
    }

    public static create(props: Props): Result<User> {
        return Ok(new User(props));
    }
}

// ------------
// Any Context - Subscribe
const context = Context.events();

type Model = { id: string; name: string; createdAt: Date; updatedAt: Date };

context.subscribe('signUp', (user: Model) => {
    console.log(user));
});

// ------------
// Account Context - Dispatch to Global Event
const user = User.signUp('Jane Doe');

context.dispatchEvent('signUp', user.toObject());

Challenges

How to maintain compatibility between browser and server?
Do we keep or remove events controlled by the aggregate instance?
Would it be better to keep the event added to the aggregate instance and fire the global event when calling the handler?

mmmoli commented 6 months ago

Love this. It's easy to see how I'd use it in the projects I'm building.

Would we get strong types?
What happens in the context of fanning-out from a single lambda function? Would we cause a chain reaction of lambdas?

Definitely keep me posted on this.

4lessandrodev commented 6 months ago

Some Points

How to maintain compatibility between browser and server?

For browser the lib add a CustomEvent to dom as global identified by provided name.

Do we keep or remove events controlled by the aggregate instance?

the aggregate continues to have event management methods, these must be used for business rules of the context in which the aggregate is inserted

Would it be better to keep the event added to the aggregate instance and fire the global event when calling the handler?

when triggering the event by the aggregate, the event for the global context will not be triggered automatically, it must be triggered by the handler or directly by the context event manually