This is the thesis of my BDD blog: jhumelsine.github.io/2024/08/08/b...

Its summary:
* TDD describes how to create a test. BDD describes what test to create.
* BDD helps us know when we’ve created enough tests to achieve confidence in our code.
* Both practices complement one another

Yes and no...
Your coordination policies won't matter at all if your teams aren't aligned with your business subdomains/capabilities.
So, designing your teams comes first.
And then designing your system's arch, f.e. microservices with event-driven comms fits nicely.
See: youtu.be/qKLnlaWKkb4?...

Doesn't solve the Q about depending on whole domain model vs just the port contract.
But it has helped me a lot in centering the conversation around the ports as contracts between inside and outside worlds.
Many devs don't get what's up with the hexagon, but they understand interfaces & contracts.

💯
Every dev has its own interpretation of what "hexagonal" means. 🤦‍♂️
That's why I prefer the "ports & adapters" name; at least it's closer to what's prescribed by this arch pattern.
All in all, this is just a pattern, not a full arch, so it requires other patterns about modularity, deps & cohesion...

It seems so natural to me that adapters can depend on any class from the domain model that I never thought about this TBH. 🤔
My 2¢ anyway: it would be too restricting for the adapter to only reference what's explicitly used in the port iface contract.
As usual, balance between purity and pragmatism.

Example please?
I don't see the problem: adapters can depend on the domain model classes (but not the other way around).
Regarding this last thing: I'm ok with domain entities having JPA annot as long as they perfectly match the persistence model AND the DB schema is not shared (priv impl detail).

If you're wondering whether (software) design is still relevant, here's a line from the talk by Kyle Kotowick about the Boeing 737 MAX:
"346 deaths and $87 billion later, we have all been reminded of the importance of rigorous design"

I agree with you on that.

My concern is just about the definition of unit test.
Many people think that "unit" refers to the extent of what's being tested, but AFAIK, it refers to the fact that the test itself doesn't depend on any external component/system.

> "Unit testing is the process of testing an individual functionality".
Is this really the case?
My understanding is that *all* tests should verify an individual behavior, so that when it fails you know why.
So, "unit test" refers to the fact that the test doesn't depend on anything external to it.