A legjobban talán Uncle Bob tudja ezt elmondani:
https://www.youtube.com/watch?v=Nsjsiz2A9mg
Kötelezően megnézendő video.
A lényeg: nem a tárolási réteg határozza meg, hogy az objektumaid mit tudnak és mit nem és hogyan kell kinézniük. A tárolási réteg csak I/O.
Mondjuk a fenti Person/Car példában:
Van egy Person, Car objektumod, amik maguk az autókereskedésbeli domain objektumok. Tartalmazzák az üzleti logikát, stb.
És mondjuk van egy PersistentStorage objektumod (ez már nem az autókereskedés domainje, hanem a perzisztens tárolás domainje), ami tud olyat, hogy PersistentStorage.persist(Person) meg PersistentStorage.restorePersonByName(name) stb.
És lehet, hogy a PersistentStorage-nek van pár implementációja, ami JPA-val, Entity Frameworkkel, tetszőleges DAO-val perzisztálja az objektumot. Ő tudja, hogy a Persontól mit kell elkérni, hogy egyértelműen perzisztálni lehessen: az ő domainje a perzisztencia, és nem a 'business logic'.
Az, hogy a JPAStorage használ PersonEntity-ket a JPA framework által diktált formátumban (sima value bag-ek, logika nélkül), attól még a business objektumaid nem value bagek.
NE a JPA framework korlátja dikálja, hogy hogyan építed fel az üzleti objektumaidat. Mert akkor a JPA-hoz és a JPA korlátaihoz leszel mindig is kötve. Pedig a JPA csak egy I/O device. Semmi köze a valódi üzleti logikádhoz.
Például mekkora szívás lenne abban az esetben, ha a JPA architektúrája diktálja az alkalmazásod architektúráját, JPA-ról áttérni iBatisra, ugye? Pedig maga az üzleti logikád NEM változik meg, miért kéne átírnod az üzleti logikát. Csak a perzisztencialogikád változik meg.
Hogy másként mondjam: nem az adatbázis/tárolási réteg/I/O réteg (pl. REST) felől építjük az alkalmazásunkat.
Hanem a business által definiált objektummodelt készítünk, amihez készítünk REST/DB/whatever interfészeket, amik az üzleti objektumainkat kiajánja HTTP felé, kiajánlja DB felé stb.