About v3 and v4 - Deprecate v3?

[4lessandrodev]

          @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?

Originally posted by @GaetanCottrez in https://github.com/4lessandrodev/type-ddd/issues/444#issuecomment-2367596702

[4lessandrodev]

@GaetanCottrez Thank you for your suggestions.

Comparison between Lerna and Turbo

Both Lerna and Turbo are tools used to manage monorepositories, but they have different approaches. Lerna is widely used to manage multiple npm packages within a single repository, facilitating versioning and individual publishing of each package. Turbo, created by Vercel, focuses on speeding up builds and sharing cache, optimizing the workflow in monorepos.

rich-domain Dependency in Each Subpackage

The presence of the rich-domain library in each subpackage is intentional because each subpackage can be installed individually. For example, when you run npm install @type-ddd/email, the installation will consider only the dependencies present in the package.json of the email package since it is published separately. This ensures that each package has all the necessary dependencies to function autonomously, without relying on the root package.json of the repository.

[4lessandrodev]

@GaetanCottrez I thought of an action plan with next steps

1. Migrate the Repository to a GitHub Organization

   • [ ] Create a new GitHub organization with a name relevant to the project.
   • [ ] Transfer the current repository to the new organization.
   • [ ] Update all links and references to the old repository in documentation and examples.

2. Deprecate Version 3 (types-ddd)

   • [ ] Mark version 3 as deprecated in the repository and in package registries (npm).
   • [ ] Add clear warnings in the documentation indicating that v3 is deprecated.
   • [ ] Communicate the deprecation to users through announcements in the README, issues, and other communication channels.

3. Create Migration Documentation

   • [ ] Develop a detailed migration guide from v3 to v4.
   • [ ] Include step-by-step instructions, code examples, and highlight changes in the API or usage.
   • [ ] Make the documentation available in the repository and any associated official website.

4. Encourage Users to Migrate to Version 4 (@type-ddd/core)

   • [ ] Highlight the benefits and improvements of v4 compared to v3.
   • [ ] Announce the new version and the deprecation of the old one in blogs, newsletters, and social media.
   • [ ] Offer community support during the migration process through issues, forums, or chats.

5. Consolidate and Update Example Repositories

   • [ ] Gather existing example repositories into an examples folder in the main repository or add links to all of them in the documentation.
   • [ ] Ensure all examples are updated to reflect the changes in v4.
   • [ ] Facilitate access to the examples so that users can better understand how to use the new version in different contexts.

6. Focus on Version 4

   • [ ] Direct development and maintenance efforts solely toward v4.
   • [ ] Monitor user feedback to identify areas for improvement.
   • [ ] Plan future updates and features based on community needs.

[GaetanCottrez]

@4lessandrodev This is a wonderful action plan!

If the community can help you with certain tasks, let us know ;-).

I would be delighted to contribute towards this transition.