How do we domain events?

[simplexityware]

First of all, I think the implementation of DDD by @daniel-jonathan is very elegant. I am 4 weeks into learning JS/TS so I cannot fully appreciate what he has done.

I like the use of generics and abstract types and classes in the framework although the type system in Typescript is full of gotchas for newbies like me to the extent I am not even sure how to finely balance the roles of type, interface, class to achieve expressive yet clean code. I think Daniel should write a book on this framework!

Ok coming to events ... since the number and variety of publishers and subscribers are dynamic in nature, without resorting to any tooling from the middleware, how do we use events in our code to facilitate debugging? Even if we start logging in every publish, listening callbacks, without a central logging service that sequence the events, how do we trace the source of a bug?

I might be missing something obvious here. Any help, ideas?

U

[daniel-jonathan]

@simplexityware Thank you for the motivating comments and first discussion for the repo :)

Your discussion is exciting for me, as it touches on a very powerful aspect of DomainJS - model traceability.

The scenario - we want to figure out what is happening in our system, but don't necessarily have a good place to start. One approach is to start logging the changes in your models. That is more challenging as we move to an event driven system, where one uses publishers and subscribers.

What I am reading in your question is "how do we log a sequential timeline of the changes in our models while our system operates asynchronously". Let's use the challenging part as an aid rather than a problem - if we break down the system into smaller parts and use the event publishing and subscribing as the natural lines within your system, we will have formed boundaries to debug. The goal will be to then confidently debug the smaller parts, and as a total, we will get better visibility into the system.

DomainJS has a feature where you can trace the changes in your entities, events, and values. This is achieved when you write the definition of your Entity, Event, or Value. For example:

export const createUser = defineEntity<User>({
  trace(user: User): void {
    // ...
  },
})

export const createUserSigninEvent = defineEvent<UserSigninEvent>({
  trace(event: UserSigninEvent): void {
    // ...
  },
})

export const createEmail = defineValue(Email, {
  trace(email: Email): void {
    // ...
  },
})

The trace hook is called after creation and updates for the Entity and after creation for the Event and Value models. Entities are the only models allowed to be updated. By definition an Event and Value don't update. One way to model the linear timeline of the system is to log within the trace hooks of the entities, events, and values. You can also take it further and log the publishing and subscription calls in the system. You can use a single logger tool to do this, which will centralize your logs. If you approach it in this way, then the aim would be to debug around the natural lines that the events create between parts of the system.

[simplexityware]

I reread the entity.ts file and found the trace method in the following type.

export type EntityLifecycle<E extends Entity> = {
  created?(entity: E): void
  trace?(entity: E): void
  attributes?: EntityAttributeLifecycleMap<E>
}

And this type is an input to both createEntity and createEntityHandler functions, becoming quite complex for me.
Could you please update the read.me to show how these 2 functions are used for tracing create and update EntityLifecycle event?
Thank you.

[daniel-jonathan]

You wouldn't actually use the createEntity method. The lifecycle type is used to build out the correct types for the created, trace, and attribute handlers. So when you write:

const createUser = defineEntity<User>({
  // ... 
}) 

Internally the createEntity method is used to create the entity types, etc... Anything to really teach there is about how TypeScript handles generics, which is not necessarily needed to be understood to use the entity module.

That said, I will be working more on the README this week and I'd be happy to incorporate more details on this.