Let's discuss on Java

“We’re not building features…
We’re reverse engineering the business.”
Old Business Analyst left the company.
Took all the domain knowledge with them.
New BA joins.
Opens Jira.
Writes:
“As discussed, implement the changes.”
No discussion. No context. No clarity.
Now the real work begins…
Read 10-year-old legacy code
Decode magic numbers
Guess business rules
Validate with production behavior 😄
At this point…
We’re not developers anymore.
We’re archaeologists.
Digging through code
Trying to understand what the business meant.

“In brownfield systems…
Code is not just implementation.
It’s undocumented business logic.”

This is why:
Ubiquitous language matters
Documentation matters
Domain knowledge transfer matters
Otherwise…
Every new feature becomes a discovery mission

Your “Event-Driven Architecture” is probably just glorified async CRUD.
⚡ 4 patterns as per Martin Fowler.
Pick wrong → system suffers silently.
Event Notification
Just a signal. Nothing more.
👉 Use when: You only need a trigger, not data.
Event-Carried StateEvent = full context. No callbacks.
👉 Use when: You hate chatty services.
Event SourcingState = replay of events.
👉 Use when: Audit, history, correctness matter.
CQRSRead ≠ Write.
Split them.
👉 Use when:
Reads are killing your system.
💣 Truth
nobody tells you:
Most teams don’t “design” EDA…They just add Kafka and pray.
🧠 Reality check:
Are your services still calling each other after events?
Is your “EDA” just REST + messaging glued together?
CQRS avoided… because it exposes bad design?
So tell me
👇Which pattern are you actually using…and which one are you avoiding on purpose?
Add to my circle, to get more insight
https://chat.whatsapp.com/DSXtWpvkTFPFlVaBezT5Pj?mode=gi_t
​