Alexandre Potvin L.

[Alexandre Potvin L. @plalx]

@codeopinion Not advocating to integrate through the DB, but why do you need versioning across modules of a monolith given all modules are always deployed atomically?

[Alexandre Potvin L. @plalx]

@devXritesh A flaw many don’t recognize is failing to ask: what business process is this query actually serving?

Are you building an ultra-generic public endpoint because the query shape/criteria are genuinely unknown, or are you over-generalizing what is really a well-defined process?

[Alexandre Potvin L. @plalx]

@javarevisited Won't match `status IS NULL` rows which certainly violates the principle of least astonishment...

[Alexandre Potvin L. @plalx]

@SumitM_X I never return any payloads other than acknowledgement & identifiers from commands so certainly not for a delete. The caller had to have the necessary context to decide to delete in the first place...

[Alexandre Potvin L. @plalx]

@SakshiSugandhi Assess impact first (what data, how critical).
Weigh downtime cost vs ongoing corruption risk.
If low-risk, keep running.
If high-risk, flip maintenance to stop damage.
Snapshot DB.
Restore from last clean point + carefully merge valid newer data.
Too nuanced for a tweet...

[Alexandre Potvin L. @plalx]

@tanujDE3180 Besides a single filtered listing endpoint you might also ask yourself which business process is being fulfilled and if it makes more sense to have an endpoint tailored to it because trying to reuse the same generic endpoints and payloads across all use cases is rarely good.

[Alexandre Potvin L. @plalx]

@adymitruk @EventModeling It's not just event modeling though. Event sourcing does make the implementation align with the model much more closely which makes it trivial to translate to a running implementation. With state-based persistence you have much more impedance mismatch and opportunities to fail.

[Alexandre Potvin L. @plalx]

@codeopinion Much-needed post. Rejecting DRY and duplicating everything for “total isolation” misses the point. Not reusing when you should can be just as damaging as over-reusing. Coupling still exists—you’ll just be forced to repeat changes in many places, assuming you even find them all.

[Alexandre Potvin L. @plalx]

@dev_maims Anybody working for real couldn't survive such awful ergonomics 😅

[Alexandre Potvin L. @plalx]

@rogson_dev @_devJNS We still need functions hosting, but not for variables indeed 😉

[Alexandre Potvin L. @plalx]

@Tech_girlll Operator precedence

[Alexandre Potvin L. @plalx]

@CodeByNZ There's no way to be productive typing on a laptop 😅

[Alexandre Potvin L. @plalx]

@fidexcode Stage hunks, diff and log graph in UI. CLI for everything else.

[Alexandre Potvin L. @plalx]

@fidexcode Other way around — the best theme always depends on ambient light. So unless you code in a cave, I’ll trust the person who optimizes their workspace over the one flexing about not doing it.

[Alexandre Potvin L. @plalx]

@VaughnVernon @vkhorikov Also when you say the directory structure looks strange, do you refer to domain/application/infrastructure because that's coming from your IDDD book 😜.

[Alexandre Potvin L. @plalx]

How would you organize shared mail concepts (MailSender, impls, EmailAddress, MailMessage) so it’s clear what’s safe for domain use? Would domain & infra layers make sense inside a Shared Kernel? I want to avoid every app needing its own ACL. @VaughnVernon @vkhorikov

[Alexandre Potvin L. @plalx]

@VaughnVernon @vkhorikov We have lots of shared code but struggle to signal what’s safe for domain use vs what’s infrastructure. E.g., a shared.mail package may expose EmailAddress and GCMailSender, but only the VO should be used in domains—not the concrete sender.

[Alexandre Potvin L. @plalx]

@VaughnVernon @vkhorikov I guess our context is somewhat special because we are a small group of developers tasked to maintain 40+ java systems where most use the same organizational spring-based framework. We try to normalize as much as possible across applications to simplify maintenance.