chore(deps): bump rich-domain from 1.23.3 to 1.23.4

[GaetanCottrez]

Bumps rich-domain from 1.23.3 to 1.23.4

[4lessandrodev]

Hey @GaetanCottrez I noticed that you forgot to update the dependency in some sub-packages. That was my mistake, and I didn’t document or communicate this earlier. To clarify now The type-ddd library has two supported versions: v3.x and v4.x.

For version v4, it is necessary to update the rich-domain dependency in every sub-package that uses it, found under /packages/*. For example, in the email package, which can be installed individually:

You’ll need to update the peerDependencies section in:

/packages/email/package.json

After updating the package.json for all relevant sub-packages, the core package should also be updated:

/packages/type-ddd/package.json

For version v3, I will handle the update, as this version is maintained on a specific branch (v3.x). For v3, it only requires updating the package.json at the root of the project.

Could you please make these adjustments for version v4? Let me know if you need any further information!

[GaetanCottrez]

Ah, my bad!
I didn’t notice that 'main' was version 4.

I’ve taken care of it.

Quick question: when do you plan to release v4 on NPM?

[4lessandrodev]

The v4 has already been published under the @type-ddd/* package structure. However, compared to the original types-ddd package, this is more of an initial release (currently version 0.0.x) for the @type-ddd organization.

I believe there’s room for improvement in terms of how we handle versioning across the packages in this structure.

If you have any suggestions on how to improve this process, I’d be happy to hear them!

You can check it out using the following link:
npm package

[GaetanCottrez]

@4lessandrodev Before starting, please feel free to reach out to me for any improvement requests.

And once again, a huge thank you for your work and for this library, truly! I use it in many projects and on a daily basis.

Here are some ideas for improvements and greater clarity.

Dependency Management

So, I don’t know exactly how Lerna works (I’m a user of Turbo created by Vercel), but for example, with Turbo, you have two strategies for managing dependencies:

• Either you assume that all your packages can access your dependency (in this case, rich-domain), so you just need to add the dependency in the root package.json (and not in the individual package.json files of the packages).
• Or the dependency is used only by one package (or 2 or 3, but not all packages), in which case, you should add the dependency only in the package.json of the specific package (and not in the global package.json of the repository).

For version 4, I noticed that all your packages contain rich-domain except the logger package. If you were using Turbo, it would be wise to remove the rich-domain dependency from the packages and keep it in the root package.json of the repository.

Even if logger could technically use rich-domain (which wouldn’t make sense), it won’t affect the build or the size of this package's build.

I don’t know if Lerna adopts the same strategies as Turbo, but if it does, I would advise keeping the dependency only in the root package.json, which will make version upgrades easier instead of having to change every package.json.

Managing v3 and v4

If v3 and v4 offer the same features and it’s just a matter of restructuring the repository into packages, then it might be wise to consider deprecating types-ddd and communicating the migration to @type-ddd/core, to stop maintaining both versions. If necessary, you could provide documentation for migrating from v3 (types-ddd) to v4 (@type-ddd/core).

Example App Based on types-ddd and @type-ddd/core

I’m not sure if it would be beneficial to consolidate your example repositories (finance-project-ddd, simple-ddd-app-example, ddd-app, ddd-demo-youtube) into an examples folder in your repository or to add links to all these repositories in your documentation (currently, only the link to ddd-app is there).

Because from my own experience, I had to look through your GitHub profile to find the examples and see how each mechanism of your library works in different contexts (especially to implement a Domain Events system with Redis Queue or SQS in my use case).

What do you think about that?