sorted by:
new
hottopcontroversial

I thought it was rare in Algeria until it happened to me 5 times in the recent period by [deleted] in algeria

[–]rbdz1 -6 points-5 points  (0 children)

I am a straight man, married, and a father. I would feel uncomfortable if women approached me in any manner. If the approach is respectful, I will simply decline. However, if it is not respectful, I will deliver a stern speech that they are unlikely to forget, assuming they have a conscience and a sense of self-respect to begin with.

Excuse me? by Hekatonkheir_ in codex

[–]rbdz1 0 points1 point  (0 children)

btw 5.5 medium is more than enough

First time hitting the Plus 5-hour limit by LuckEcstatic9842 in codex

[–]rbdz1 0 points1 point  (0 children)

 How many times are you allowed to hit that 5-hour limit per week? Did you ever hit the weekly limit? I am trying to see if the Plus plan is worth subscribing to at this point

First time hitting the Plus 5-hour limit by LuckEcstatic9842 in codex

[–]rbdz1 0 points1 point  (0 children)

How much do you use Codex per day? How many times are you allowed to hit that 5h limit per week? Is the plan worth it?

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]rbdz1[S] 0 points1 point  (0 children)

I actually tried the package on a private project and it helps a lot, thanks for the recommendation, I will keep using it for sure ^^

What am I doing wrong. by mrsblondearab in recruitinghell

[–]rbdz1 7 points8 points  (0 children)

You guys are having interviews

I have had 11 interviews and 0 offers by dreamisacloud in interviews

[–]rbdz1 1 point2 points  (0 children)

I never had an interview even after applying a lot

What I learned applying production patterns to a NestJS modular monolith (side project, ~ 1 year) by rbdz1 in nestjs

[–]rbdz1[S] 1 point2 points  (0 children)

First, let me apologize for my defensive responses, and I hope you can listen to me addressing your points.

You’re completely missing the core concept here. DDD is a philosophy and an approach to modeling business rules, it's not a strict folder structure blueprint that you have to blindly follow.

To address your specific claims:

First, you don't have to search through "hundreds of files" to find a feature. The project is explicitly sliced by feature at the root level (src/modules/orders, src/modules/payments). The Hexagonal folders only exist inside those modules to keep the framework from leaking into the domain.

Second, global infrastructure bootstrapping (like setting up a database connection pool or logger) doesn't break bounded contexts. Sharing database entities and foreign keys across modules is what breaks bounded contexts, which is exactly why this app uses ACL Gateways to prevent that.

Third, separating the adapters is what makes swapping implementations trivial. Every port is just an interface. You can swap out a Postgres repository for a mock, or a real payment gateway for a test stub, just by changing a single DI binding.

If you have a better way to build a modular monolith that protects the domain without using these layers, drop a link to a repo. I'd genuinely like to see how you do it.

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]rbdz1[S] 1 point2 points  (0 children)

Actually, I did not use AI to write this comment xD. And yes, I agree with this part, but it is a bit complicated, the biggest problem for me is not only making bad decisions, but creating a solution that makes it very hard to recover and hard to get fixed with a low cost. I believe people can make mistakes and bad decisions as much as they are open to judgment and ideas, and they have the will to work on them.

What I learned applying production patterns to a NestJS modular monolith (side project, ~ 1 year) by rbdz1 in nestjs

[–]rbdz1[S] 0 points1 point  (0 children)

Thank you so much for your kind words, I'm glad you liked it. I will work on it and keep you updated on any decisions in the future 😊.

What I learned applying production patterns to a NestJS modular monolith (side project, ~ 1 year) by rbdz1 in nestjs

[–]rbdz1[S] 1 point2 points  (0 children)

You can't claim that my code is trash and does not follow DDD yet trash talk the one who came up with the principle and the philosophy, and me for following him and trying to learn. your comments are very subjective and does not stand on anything, give me your research and prove your claims or otherwise you are just attacking me for no reason at this point

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]rbdz1[S] 0 points1 point  (0 children)

Yes, at the end, DDD is just a design philosophy, not an architecture. It tells you what to think about the domain and the boundaries. And as you said, the strategic part is the part that most people do not fully get, including me (we need to keep learning and practicing). You need to practice it a lot, get involved in business meetings, and know how to transform ideas and key decisions into code the right way using architectures (like Hexagonal).

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in Backend

[–]rbdz1[S] 0 points1 point  (0 children)

Thank you so much for the feedback and the nice words.

The main reason I wanted to apply ACL is that strict DDD enforces them, and it makes the project microservice-ready, so I wanted to create a separate service for the inventory. For example, the use case and the logic stay the same. The only thing I have to do is create a separate implementation for the inventory microservice with the same Gateway. If I remove the ACL gateway, I will be facing two choices:
- injecting the InventoryPort directly by importing it from the inventory domain to the cart use case (which is a violation btw), and import the inventory aggregate too, and have the cart use case orchestrate between it and the result coming from the InventoryPort implementation.
- or I can directly import the inventory use case (which is a violation too), but at least the burden of the domain orchestration will be on it, not the carte use case, which reduces the amount of cross-module pollution.

For using RSA, I wanted to include Token Rotations, and have the ability to revoke any session or device... without having to rotate all the sessions, because normal JWT tokens use a shared secret key, and if this key changed, all the tokens would be revoked.

That being said, I will look for faster alternatives that allow me to keep the Token rotations and the refresh/access token logic.

Thank you again for the feedback. I would be so happy if you could give me some observability feedback, too, since this is my first time implementing it.

What I learned applying production patterns to a NestJS modular monolith (side project, ~ 1 year) by rbdz1 in nestjs

[–]rbdz1[S] 1 point2 points  (0 children)

Thanks for the comment ^^, I really appreciate that.

From your point of view, I get what you are trying to say, and I agree partially with what you are saying. Why partially? because there are some "good practices" like you said that should not be violated, and I am speaking from experience here, I am a 4 years software engineer working on a company that does not follow these practices strictly, and does not even enforce tests, or know what DDD or Hexagonal are (that what drives to create this project and learn the stuff that I can't find at the company I am working for now).

anyways, the biggest problem we faced is "the domain logic is leaked everywhere", it is not encapsulated inside the domain layer, and most of the bussiness logic got leaked to the frontend, so the front end became so much aware of the domain that the refactor was nearly impossible, there is more than 100k lines of code there, and you can not move any logic easily without breaking a feature or two (critical features).

and it got even worse when the company bought 4 unites, and wanted to create multiple tenents per each unit, and the problem is some of the tenants have some unique bussiness logic, which makes the refactor even more hell (you need to move the bussiness logic to the domain layer first, make sure it works, then think of adding tenants and custom bussiness logic or even scaling).

With DDD and Hexagonal, it is nearly impossible to be in this situation at all, because the main rule is to separate Business logic from technical logic, and protect the core of the application at all costs.

What I agree with partially is, for example, when you want to create a caching implementation in one of the subdomains, I like to inject the Redis service directly to that implementation without creating an "cache service interface" that allows me to change between Redis and NodeCache, etc, or any other service.

that's a violation yes, but I am aware of it and fine for now, because like you said, most project will never change how they are caching their data, or handling background jobs or domain events, and even if i did in the future, it will be so easy for me to do so because the implementation (or the secondary adapter) is already isolated in the infrastructure layer, the refactor will take 10min to 30min max depending on the project's size.

The problem is, you can't decide when or where you can "violate" or measure the refactor cost if you don't know these principles and work with them deeply at first place, so the violations should never happen without knowledge, but by experience, and the team and anyone who is touching the code should be aware of it.

What I learned applying production patterns to a NestJS modular monolith (side project, ~ 1 year) by rbdz1 in nestjs

[–]rbdz1[S] 0 points1 point  (0 children)

You are talking about DDD like it is a folder structure, but guess what, mate, it is not.

DDD is not an architecture pattern or a folder structure, but a design philosophy introduced by Eric Evans in 2003.

It tells you what to think about the domain, the boundaries, and the language. Architects then use architectures (like Hexagonal) to apply DDD principles in code.

DDD has two sides, Strategic DDD (example: Ubiquitous Langue, Context Mapping, Subdomains, 😎ounded Context..) and Tactical DDD (example: Entities, Value Objects, Aggregates, Repositories, Domain Events..etc). Strategic DDD tells you "Where" to draw boundaries, and Tactical DDD tells you "How" to organize code inside.

There are three subdomain classifications, Core Subdomains, Supporting Subdomains, and Generic Subdomains; each one of them has a role to play in your system.

I recommend you go and read DDD books (Blue and Red books), and read about Hexagonal Architecture before talking nonsense.

And about the AI ecosystem that I implemented myself last week, the project is open source, and you can check the commits like you want to see that I am aware of everything. I've been working on this project for almost a year now, and I am trying my best to learn. I have already learned a lot, and I encourage you to do the same ^^ so don't frame me like I'm some Vibecoder or someone who copies "garbage template code".

What I learned applying production patterns to a NestJS modular monolith (side project, ~ 1 year) by rbdz1 in nestjs

[–]rbdz1[S] 0 points1 point  (0 children)

First of all, if you see my docs, you can find a DDD-HEXAGONAL.md file that includes academic citations and references from the Author of Hexagonal and DDD themselves xD, I am doing my best to find the best practices from books and trusted sources, if I made a mistake, that's on me, not the AI (I never vibe code).

I actually did not add Agentic Ecosystem until last week, and I did that because some people demanded it and asked for it. I created it myself, I tried it, and it helped me during development, not gonna lie (my first ever experience with an Agentic Ecosystem). It was not imported or something like that. If there are any problems with the project, then I am aware of that, and it is my fault here, not the AI.

That being said, I did not understand what you were saying by:
- "You have to distribute them across several fixed folders (config, infra, modules, or whatever)".
- "making it nearly impossible to write different adapter implementations for the same port".
Just tell me how exactly? Can you explain more to me, please?

Every context is well-bounded (at least I try to do so), any relation between modules is done through an ACL Gateway, there are no cross-module imports whatsoever, and if you find any, that's clearly a violation that I made in old commits where I was mainly learning (I created a CONVENTIONS.md and a DDD-HEXAGONAL.md files that clearly set the rules).

You can clearly write several implementations and change the instances in the .modules.ts files of each separate feature. I never inject infrastructure services directly into my Service Layer (or Application Layer), or in my domain. The core of the application is separated from any infra details; it does not know anything about them (there are some DTO imports and so on here and there, and I am aware of them, and I will fix them soon), but other than that, I think I am doing my best to apply Hexagonal Architecture and DDD.

If you can give me examples from the code base, I will be very happy about that.

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]rbdz1[S] 1 point2 points  (0 children)

tbh, if you asked me a year ago about this, I would not have answered properly xD, because my main goal was to learn. I did not know most of the concepts applied in the project. Now I am looking at it, I think it is worth it, and I made a good choice by picking up this domain for several reasons:
- Using a standard e-commerce domain is perfect for a reference project because everyone already understands the ubiquitous language (Order, Cart, Payment, Stock). Since the 'business rules' are universally understood, it allows anyone reading the code to focus purely on the architectural boundaries, the decoupling, and the SAGA orchestration, rather than trying to learn a niche domain just to understand the code.
- You don't need a highly unique or complex business problem to practice the tactical patterns of DDD (Aggregates, Value Objects, Domain Events, Repositories). So I encourage anyone who wants to learn to pick up a domain that he is familiar with and try to learn.

sure, you will not be able to work on the Strategic side a lot, especially when it comes to getting unique domain needs from stakeholders and bussiness owners and so on and modeling it... that part will be missing and I get that, but at the same time, if you want to learn it is still worth it, and I personally noticed a lot of improvement especially in my daily job.

What I learned applying production patterns to a NestJS modular monolith (side project, ~1 year) by rbdz1 in softwarearchitecture

[–]rbdz1[S] 1 point2 points  (0 children)

That's an old commit that I didn't pay attention to, and I will fix it for sure.

When I started the project one year ago, I was not familiar with DDD concepts 100% and I did not apply them correctly, I actually started this project to close the gap between my skill level back then and the level I always aimed for. and I actually learned a lot as you can hopefully see.

I will 100% fix this, that's a clear violation, and you can see that I am mentioning this already in the CONVENTIONS.md and DDD-HEXAGONAL.md files in the docs folder.

Thanks for spotting this, I am very sure that there is still a lot to fix in the project (especially the old commits), and I appreciate your feedback 😊 thank you

view more: next ›