Introducing 

Prezi AI.

Your new presentation assistant.

Refine, enhance, and tailor your content, source relevant images, and edit visuals quicker than ever before.

Loading…
Transcript

Azt modellezzük, amit eddig papíron, elavult szoftverrel végeztek

Ugyanaz a nyelv mindenhol

  • A modelben
  • A szoftverben
  • Az ügyfél kommunikációban

Ki ismeri a domaint?

Ha a nyelv közös, mindenki számára könnyebben átláthatók a folyamatok.

DDD megoldás

Domain Expert

Többnyire az ügyfél oldalon van

Aggregate root

Hogy fejlesszünk szoftvert,

ha nem ismerjük a témát?

Tipikus megoldás

Az a téma, amelyben dolgozunk, amelyben szoftvert írunk

Domain

A model

És a service

ValueObject

Meg kell értenünk és elsajátítanunk az ügyfél

  • Folyamatait
  • Szakzsargont

Cél

Az exceptionök

a korábbi serviceből

setterek eltűntek

Ubiquitous

Language

Üzleti logika

Anemic domain model

Transaction script

Ez OOP?

Tranzakciós határ

Törlés és mentés egyszerre

Aggregate

Problémák

  • Bonyolult gráf a modellek között
  • Több Entityn - VO-n átívelő invariánsok

Optimistic locking?

  • ORM - Lazy load

Sose tudhatjuk, mikor fut le egy query

  • Csak egymásról és más kiemelt entitykről tudhatnak
  • Lokális ID

Belső Entityk, VO-k

  • A teljes csoportért felel
  • Invariánsok betartása
  • A többi elemet elrejti a külvilág elől
  • Optimistic locking
  • Globálisan egyedi azonosító (ID)

Aggregate Root

Kiemelt Entity

Csoportosítsuk az entityket és VO-kat

Entity

  • Egyedi azonosító
  • Életciklus

fontos a sorszám is

csak az érték a fontos

Pénznyomda

Pénzváltásnál

A bankjegy Entity vagy VO?

ValueObject

  • Érték alapján azonosítjuk
  • Két objektum megyezik, ha értékeik megegyeznek
  • Nem buta DTO!
  • Immutable!

Service

Valaminek még nincs helye...

Üzleti folyamatok, de valamiért nem tehetjük őket modellekbe

Például repositorykra,

factorykra van szükség

  • Stateless
  • Az implementáció gyakran az infrastructure rétegben van
  • Domain modellek a metódus paraméterek és visszatérési értékek

Új objektumok létrehozása

  • Már meglévők segítségével, de csak ha kivitelezhető és logikus is
  • Egyéb esetben egyszerűen csak new

És ha mondjuk repository kell hozzá?

Ne adjuk át az entitynek

a repositoryt!

Factory

Példa: Csocsó

  • 2 csapat van, akiket a nevükkel azonosítunk
  • összesen 10 labda van
  • az nyer, aki több gólt lőtt
  • döntetlen esetén az utoljára gólt szerző csapat nyer

Hogy csinálnánk?

Java, ORM, Service

Domain

Layered

architecture

Új objektumokat

nem itt hozunk létre!

Perzisztencia?

  • Interface a domain rétegben
  • Az implementáció viszont az infrastructure rétegben

pl.: JpaMatchRepository

  • Csak aggregate rootokhoz - a belső objektumokat majd azokon keresztül elérjük

Repository

Aggregaten belül eager loading - kezelhető legyen

Infrastructure

Application

Domain

User interface

Üzleti logika

Izolált a többi rétegtől

Konkrét implementációk

Controller

Facade

DTO

Koordinátor szerep

Services

  • Tranzakciók
  • Stateless
  • Minimalizáljuk a méretét

Application Event (JMS, stb.)

Perzisztencia

E-mail küldés

HTTP és egyéb kommunikáció

Gyors unit test

A logika egy helyen, minden más máshol

Domain-Driven Design

Domain Event

Eric Evans

DDD szabályszegés

Entitykben getterek - elérhetők az aggregatek belső elemei

Komplexitás

Konvertálás DTO-ra

Bonyolult lekérdezések

Problémák

Bertrand Meyer - CQS

Command

Query

(Command-Query Separation)

Alkalmazzuk magasabb szinten

Kell nekünk az ORM?

Redundancia

Event

Aggregate

Event storage ugyanazt tárolja, amit az ORM kiszámol aggregate változásnál.

Felhasználói beavatkozás, üzleti folyamatként definiált

Domain Event

getter, setter

Megjelenítéshez adatlekérés

Client -> Server

Utasítás, amit a felhasználó tenni kíván

Végeredmény: metódus hívás entityn a küldött paraméterekkel

Szerializált metódushívás

Command

Már bekövetkezett

Pl.: ScoreBlue

Query Storage frissítése

Domain Event

Immutability!

Pl.: BlueTeamWon

Nem feltétlenül két storage

http://blogs.msdn.com/b/cesardelatorre/archive/2012/02/22/cqrs-bus-and-windows-azure-technologies.aspx

Két model

  • Domain model
  • Üzleti logika

Write model

  • Denormalizált
  • UI-nak kényelmes
  • View table, vagy akár NoSQL

Read model

CQRS

(Command Query Responsibility Segregation)

Greg Young

Event Sourcing

Bármely időpillanatra a rendszer visszaállítható

  • még nem definiált reportok

Nem csak az utolsó állapotot tárolja (bankszámla)

Given: loadFromHistory()

When: command

Then: events

Teljesítmény: 10.000 tranzakció / sec.

public void loadFromHistory(List<Event> events);

Ha túl sok az event, akkor snapshoting

-> szerializálva tároljuk az aggregatet is

Event és Aggregate adatbázis tábla (össz. 2)

Eventek == Audit log

Tesztelés?

Következmények

Interface nem változott!

Megvalósítás

Aggregate

Nincs ORM

Nincs Exception dobás!

  • Inicializálás: Event listából
  • Command metódusok: ellenőrzés és kivétel dobás, végül event "elsütés"
  • Event feldolgozás: nincs exception, folyamat végrehajtása

Források

Eric Evans

Vaughn Vernon

InfoQ

Implementing Domain-Driven Design

Domain-Driven Design: Tackling Complexity in the Heart of Software

Effective Aggregate Design - http://dddcommunity.org/library/vernon_2011/

Domain-Driven Design Quickly - http://www.infoq.com/minibooks/domain-driven-design-quickly

http://dddsample.sourceforge.net/

Példa alkalmazás (Spring)

Szurovecz János

szjani@szjani.hu

Learn more about creating dynamic, engaging presentations with Prezi