Události domény vs. události integrace

Navrhování aplikace může být někdy obtížné, zvláště pokud navrhujete několik domén a musí vzájemně komunikovat. Abychom těmto komplikacím zabránili, můžeme využít některé koncepty a implementace v naší aplikaci.

V tomto příspěvku se podělím o některé myšlenky týkající se doménových událostí a integračních událostí, několika praktických příkladů a uvedu je do souvislosti s návrhem aplikace.

Události domény

Co je to?
Podle Martina Fowlera doménová událost „zachycuje paměť něčeho zajímavého, co ovlivňuje doménu“.

Co je to ve skutečném světě?
Řekněme, že John a Mark pracují společně v prodejní oblasti společnosti a dělají nějaké papírování. Za prvé, John vytvoří ručně psaný rozpočet tím, že vezme požadavek zákazníka a vypočítá nějaké daně. Poté Mark vezme tento papír a odfaxuje jej zákazníkovi (stále existuje?).

Na základě tohoto příběhu si můžeme všimnout, že Markova práce souvisí s Johnovou prací, ale nemusí být nutně svázaná. Například Mark může čekat na všechny rozpočty na den a poté je poslat zákazníkům.

Jinými slovy, vytvoření rozpočtu je součástí stejné domény informování zákazníka o tomto rozpočtu, ale tyto akce nejsou součástí stejného procesu.

Nakonec máme vytvořenou „paměť“ rozpočtu, která ovlivňuje „prodejní doménu“, pomocí této paměti odesíláme rozpočet zákazníkovi.

A co návrh aplikace?
Musí být implementovány v konkrétní doméně nebo stejné logické aplikaci. Jeho hranice musí být velmi dobře ohraničeny.
Pokud navrhneme aplikaci pro náš příběh, měli bychom následující scénář:

Jedna aplikace, která vezme požadavek zákazníka, vypočítá daně, zaregistruje rozpočet a poté zveřejní událost, že rozpočet byl vytvořen.
Sekundární proces by se přihlásil k odběru událostí v doméně, začal poslouchat událost „vytvořený rozpočet“ a poté, když dojde k této paměti, zašle zákazníkovi e-mail.

Jaké jsou z toho výhody?
Mohu vyčíslit některé výhody:

  • Oddělení obav, usnadňující vaše údržbové procesy;
  • Dobré modelování kódu pomocí konceptu všudypřítomného jazyka.
  • Testovatelnost, protože proces nezávisí na druhém.

Integrační události

Co je to?
Závazek, ke kterému došlo v minulosti v omezeném kontextu, který může být zajímavý pro jiné domény, aplikace nebo služby třetích stran.

Co je to ve skutečném světě?
Nyní řekněme, že když John dokončí svou práci, jde do marketingového oddělení společnosti a doručí kopii rozpočtu. S touto kopií v ruce vybere Julia několik dobrých zákazníků, aby při příštích nákupech dodali speciální slevový kupón.

Po přidání této části příběhu můžeme poznamenat, že Julia je součástí jiné domény s názvem Marketingová doména.

Také si všimněte, že stejná událost se stala v minulosti (vytvořený rozpočet), ale nyní v jiné doméně. To znamená, že nemusí vědět, jak byl rozpočet vytvořen, vypočítán nebo dokonce poslán zákazníkovi. Potřebuje jen dokončit svou marketingovou práci.

A co návrh aplikace?
Tento scénář není zaměřen na konkrétní návrh aplikace, ale na celý systém. Když se zabýváme distribuovanými systémy, můžeme uvažovat o dvou oddělených aplikacích: Prodej a Marketing.

Prodejní aplikace vydává událost „vytvořený rozpočet“ a poté aplikace Marketing reaguje na tuto událost a odešle marketingové kampaně.

Jaké jsou z toho výhody?

  • Oddělení obav na celé úrovni systému, protože systém prodeje nechce vědět o procesech zahrnutých v jiných systémech po události „vytvoření rozpočtu“. A další zájmové domény se nyní mohou přihlásit k odběru této události, aniž by věděly, jak k ní došlo, ale kdy k ní došlo.
  • Škálovatelnost. Pokud prodejní tým bude tvrdě pracovat, dokud se nevytvoří bod stovek rozpočtů, můžete otevřít více „pracovníků“, kteří poslouchají tuto frontu událostí, a práci zvládnete s rostoucí zátěží.
  • Dalším aspektem je to, že projekty můžete rozdělit mezi týmy, považovat je za produkty a mohou pracovat, rozvíjet, měnit pravidla, aniž by tím ostatní obtěžovaly.

Závěrečné myšlenky

Tyto koncepty zvyšují kvalitu vašeho softwaru, ale při navrhování systému musíte být rozumní.

Události v doméně a události integrace mohou usnadnit váš život, ale musíte se postarat o to, kdy je to potřeba. Například, pokud potřebujete vytvořit jednoduchou aplikaci CRUD a už se nejedná o nic víc, určitě nemusíte navrhovat obrovské architektury, které by to zvládly. Jen buďte rozumní a udržujte to jednoduché.

Tento článek je k dispozici také v portugalštině.