Random reminder that I have a YouTube channel where I post videos about software architecture and design. Usually in the 10 min range trying be concise as possible. If you enjoy please share. Have suggestions? Please let me know. piped.video/@codeopinion

Alan K. said what was important: the messages in between the objects; that always been the tricky part ... The older I get, the less I care about algorithms, data structures, and programming languages. Ai accelerated that. Most algorithms, data structures, and programming languages are render trivial given that you understand the data, information and messaging between your components. That is also why, sometimes, it is better to hire somebody with the domain knowledge than somebody that is purely very good at programming. One of them is too expensive to get it wrong, and I testify this by the only failure in my entire career that I attribute to myself alone, and, it was not a problem of hard programming skills, but the fact I was not fast enough to discover all edge cases around the data. The wisdom to avoid dead ends, and what NOT to do, comes from the understanding of the data in most contexts.

Multi-Tenant "Best Practices" often hide trade-offs. Where complexity really goes when using tenant context, shared databases, filtering, and feature flags.

Avoid API Breaking Changes - codeopinion.com/avoid-api-br… @codeopinion

A lot of software architecture and design is really just about where you want the coupling to live and the trade-offs around it. Yet I seemingly almost never hear people explicitly saying that's what's going on. I genuinely think that if people acknowledged that, the decisions would be much easier to make.

Good integration events don't just announce that data changed. They communicate a meaningful business event to other systems. Integration events are part of your public API. Design them deliberately. codeopinion.com/domain-event…

Domain Events are NOT your Public API - codeopinion.com/domain-event… @codeopinion

I keep seeing this take. The "abstraction is going up a layer" is a weak argument because an abstraction layer gives you a _stable_ contract. AI can let you operate with less detail locally (which is awesome), but calling it a new abstraction layer, as if it were a compiler, when it's a non-deterministic collaborator... no.

Brain dump: Tests and evals can only validate the things you thought to test. Not what you didn't. I’m skeptical that we can stop reviewing code and just evaluate outcomes. Looking at the implementation can reveal things you never thought to write an eval for: bad assumptions, unintended behavior, coupling... all could pass but still be "not good". Reviewing the code is one way you discover what you didn’t know. Again, just a brain dump...

Don't expose internal domain events across service boundaries. When you treat domain events as your public integration contracts, you couple consumers to your internal domain model and workflows, leading to breaking changes and a fragile system that's hard to change.

If you’re using event driven architecture and asynchronous messaging, you need to be clear about what you’re actually doing. You’re not necessarily decoupled just because you removed direct synchronous calls. codeopinion.com/event-driven…

Event-driven architecture promises loose coupling, but are you actually decoupled? @codeopinion on the hidden temporal, semantic, and behavioral coupling that survives even after you add a message bus. #eventdriven #distributedsystems codeopinion.com/event-driven…

Are you just shipping a CRUD API over pub/sub messaging and calling yourself "event-driven"? @codeopinion has a good post about modeling events around business concepts and behaviors. codeopinion.com/event-driven…

A member of my CodeOpinon group took all my YouTube transcripts and turned them into agent skills. Really cool idea by Essam Almansouri! github.com/eralmansouri/skil…

Coupling. If you haven't yet gotten tired of me saying it. Coupling.

I think people are stuck in their own bubble of how software teams work. Eg, I haven’t worked in sprints for 10 years. Mostly continuous flow, small pieces of work, and constantly changing priorities. Code matters. But if all you were doing was turning tickets/issues into code while following existing guidelines, you were mostly typing. In complex domains, the value is understanding the business. That can take years to develop. I'd argue that assuming reasonable technical skills, deep domain knowledge is often more valuable than technical ability. Especially because that understanding ultimately shapes how the domain gets represented in the system.

Event driven architecture doesn't mean you aren't coupled. Especially when your events are really just database changes being broadcast over a message broker.

I've always thought developers should understand the layer of abstraction below the tool they're using. If you're using an ORM, understand SQL is a smple example. If you're building HTTP APIs, understand HTTP methods, status codes, headers, caching, idempotency etc. Abstractions are useful. Understanding what they abstract away is still as relevant as ever. Just because you might not be writing the code doesn't mean you shouldn't understand it. Just my take.

Holy shit someone posted something insightful and honest on here