Doctrine: bounded context a schema tool

Ahoj,

ano, jde toho docílit naštěstí, a to Single table inheritance

vytvoříš si nějakou entitu „BaseOrder“ ve které budeš mít identifikátor entity a tu podědíš do dvou různých entit pro různé kontexty.

Děkuji za odpovědi. Potřeboval jsem chvilku času, aby se v tom pohrabal.

@MajklNajt: s tou dědičností je dobrá poznámka.

přiznám se, že vůbec nerozumí, jak v tomto případě použít OneToOne relaci – tu přece používáme, abychom do jedné entity vložily data ze dvou tabulek. Ale já chci mí data nadále uložena v jedné tabulce. Můžeš tu myšlenku trochu rozvinout?

@JanEndel : zkoušel jsem to a bohužel to nefunguje – pravděpodobně jsem něco nepochopil. Když se vrátím zpátky do stavu „Aktuální stav“ popisovaný v mém prvním příspěvku, tak udělám:

1. vytvořím abstraktní BaseOrder (přidal ji anotaci @InheritanceType("SINGLE_TABLE") a samozřejmě @Entity), doplním protected $id s odpovídající anotací
2. původní objednávku přejmenuji na DefaultOrder (já vím, debilní název, ale zatím nevadí), odeberu $id a nastavím, že dědí od BaseOrder
3. vytvořím novou objdnávku např FooOrder (zase doplním anotace @Entity, zase dědí od BaseOrder)

Nic víc, nic míň a když teďka chci vytáhnout jednu FooOrder (např. dle ID), tak mi to píše, že nemáže najít sloupec dtype. (Protože je to výchozí sloupec na základě chce Doctrine rozhodnout, zda použije FooOrder nebo DefaultOrder: viz https://www.doctrine-project.org/…ference.html#…)

Opravdu je Single table inheritance ta správná cesta? já přece nechci aby doctrine rozhodovala o tom, jakou entitu má vytáhnout, já ji to explicitně říkám v tý query:

/**
 * @param int $id
 * @return Query
 */
protected function createQuery(int $id)
{
    return $this->entityManager->createQueryBuilder()
        ->select('u')
        ->from(App\Model\Orm\FooOrder, 'u') // nebo klidně App\Model\Orm\CreateOrderContext\Order - to je jedno
        ->andWhere('u.id = :id')->setParameter('id', $id)
        ->getQuery();
}

Nikdy jsem to realne takto striktne neimplementoval. Ale take nevim, jak bych to s Doctrine resil. U ActiveRecord nebo DoctrineDBAL by to slo snadneji, ale tam to zase neni uplne DDD.

Trochu se mi zda, ze by mohlo pomoci CQRS, kde celkem jasne oddelen zapis a cteni. Takze se ti nemuze stat, ze by jsi me v pameti, jak rikas, 2 entity.

Pripadne mit vice mikrosluzeb, kde kazda cast by si to vyresila podle sebe. Tak ci onak, na tohle je potreba imho myslet na zacatku a dobre to rozmyslet. Neni lehke to pak menit.

Ale treba by mel nekdo jiny nazor. :)

Ahoj @fordo.pytlik, ja si práveže myslím, že cieľom toho všetkého je rozsekať jednu entitu na 3 samostatné entity, ktoré budú iba prepojené (preto som písal o OneToOne relácií). Prednášku o DDD som pochopil tak, že vo všetkých kontextoch použijem entitu s rovnakým názvom Order (rozdiel bude napr. iba v namespace), avšak v každom kontexte využívam (tým pádom aj mapujem) iné properties, pretože v kontexte expedície nikoho nezajíma fakturačná adresa, dátum objednávky ani pod akým symbolom očakávam úhradu, zaujímajú ma napr. len položky a adresa dodania; v kontexte párovania platby s objednávkou ma zas zaujíma práve ten variabilný symbol, ale je mi jedno, či je to objednávky ponožiek alebo jadrovej ponorky, riešim len zaevidovanie platby…

Ty to zrejme chceš napchať do jednej tabuľky, ja by som to naopak rozdelil kľudne do viacerých tabuliek, koniec koncov, pri modelovaní objektov by ťa štruktúra SQL ani nejako nemala trápiť :)