Korelacja pomiędzy obiektami domenowymi a tabelami w bazie

Cześć,

Od jakiegoś czasu zastanawiam się nad odpowiednim podejściem do tematu.
Zakładamy, że chce użyć ORM'a do zarządzania stanem obiektu w bazie danych.

Przykład produktu oczywiście
Mam produkt w trzech kontekstach np. Magazyn, Marketing, Zamówienia

Oczywiście w każdym kontekście produkt ma lub może mieć inne zachowania, co za tym idzie inne dane, na których zachowania operują.
Idąc dalej w aplikacji mamy 3 klasy. Co jeśli chce skorzystać z ORM'a?

Czy powinienem mieć Entity Product, który służy mi za Correlation Object i trzymał w sobie będzie Correlation Id
Natomiast każdy z trzech kontekstów powinien również dostać swoją Encję razem z polem CorrelationId?
Co za tym idzie, nawet na poziomie bazy danych będę miał to rodzielenie.

Czy są może jeszcze inne sposoby aby to zrobić?

No ale masz produkt który będzie ciągłe w relacji z innymi kontekstami. Według mnie rozumowanie jest w zasadzie prawidłowe, tylko nazewnictwo kolumn/modeli dziwne.
Może narysuj diagram i wrzuć lub stwórz na szybko jakiś DDL tych tabeli.

Zrób to w podejściu db-first. Najpierw zamodeluj poprawne tabele i relacje odpowiadające domenie biznesowej, a dopiero później opisz je za pomocą wybranego ORM-a.

Kuba Leman napisał(a):

Czy powinienem mieć Entity Product, który służy mi za Correlation Object i trzymał w sobie będzie Correlation Id
Natomiast każdy z trzech kontekstów powinien również dostać swoją Encję razem z polem CorrelationId?
Co za tym idzie, nawet na poziomie bazy danych będę miał to rodzielenie.

Moja rada, to nie próbuj na siłę łączyć obiektów domenowych i tych obiektów z ORM. To jest błąd żeby starać się je do siebie upodobnić. Zrób ORM i baze osobno, i obiekty domenowe osobno.

Teraz zrobię wywód - ORM to moim zdaniem oksymoron, niby znaczy "object-relation mapping", a coś takiego jest nie możliwe, bo obiekty mają enkapsulować szczegóły implementacyjne i zachowanie, a tabele w SQL to "gołe" dane, więc mapowanie ich 1:1 jest niemożliwe. Ja nazwałbym to SRM - structure-relation mapping, tylko wtedy mogłoby to nie być tak popularne ;D

Kuba Leman napisał(a):

Oczywiście w każdym kontekście produkt ma lub może mieć inne zachowania, co za tym idzie inne dane, na których zachowania operują.

że co?