Java, the Domain Driven Cult

I've done enterprise Java since the mid-2000's, before that, .NET (early .NET) then C++ before that, mostly SV startups.

Today I saw a reference to @Embeddable and had never seen it or used it out of many companies I've worked for. I went down an interesting rabbit hole with Gemini, but it'd probably have been similar with any AI.

What I discovered is there is this group (I prefer to think of them as a cult) that reminds me of the TDD and BDD groups (cults) called the DDD (Domain Driven Design) group (cult).

Apparently @Embeddable/@Embedded concept is their doing.

I could go through a list or arguments for @Entity and against @Embeddable but the AI summary is more succinct and frankly states the cases clearly, if I may:

SCENARIO: @EMBEDDABLE vs. @ENTITY

| FEATURE | USE @EMBEDDABLE | USE @ENTITY |

| Object Lifecycle | Address dies with User | Address exists on its own |

| Storage | In User table (Flat) | In Address table (Norm) |

| Complexity | No FKs; No Joins | Requires @OneToOne/@Many |

| Querying | Must query via User | Can query Address directly |

| Database Schema | One table (Users) | Two tables (Users, Addrs) |

| Identity | No ID; value-defined | Has its own Primary Key |

I find it difficult to imagine that anyone working with microservices in the enterprise would allow coders to use @Embeddedable. One major caveat with using it, aside from that one "Address dies with the User"; "If you ever find yourself in a situation where you are forced to use @Embedded for two different addresses in the same class (like homeAddress and billingAddress), you'll need @AttributeOverrides to avoid column name collisions.".

Name collisions, oh boy, that sounds fun. Friends don't let friends use @Embeddable.