Domain Driven Design

Koncepcja, podstawowe składniki (pojęcia) i building blocks DDD.

Transcript

1. Domain-Driven Design Czym jest DDD? Dlaczego warto? 2014-12-15
2. Krzysztof Kąkol Team Leader – Software Developer O nas 2014-12-16 2 Michał Kozłowski Software Developer
3. • Technologią • Metodologią Czym NIE JEST Domain-driven design? 2014-12-16 3
4. • Sposobem myślenia • Zestawem priorytetów i wskazówek Czym zatem JEST? 2014-12-16 4
5. 1. Dlaczego właściwie Domain-Driven Design? 2. Podstawowe składniki DDD 3. Building blocks Domain-Driven Design 2014-12-16 5
6. Dlaczego właściwie DDD? 2014-12-16 6
7. 1. Dlaczego właściwie DDD? 2014-12-16 7 Piszemy kod… Tworzymy oprogramowanie… Rozumiemy potrzeby klienta… ROZWIĄZUJEMY PROBLEMY
8. Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software 1. Dlaczego właściwie DDD? 2014-12-16 8 Problemy Nowy język Biblioteki Magiczne metody Cudowne akronimy Nowe serwery Nowy framework Nowy sposób myślenia
9. • Zasady i wzorce • Testowalność kodu • Problemy i język domeny • Zgodne z doświadczeniem 1. Dlaczego właściwie DDD? 2014-12-16 9
10. Podstawowe składniki 2014-12-16 10
11. • Specjalista w wybranej domenie/dziedzinie • Dostępność eksperta domenowego dla zespołu • Ekspert dostarcza opisów zachowań 2. Podstawowe składniki 2014-12-16 11 Ekspert domenowy (domain expert)
12. • Core domain • Generic/supporting subdomains 2. Podstawowe składniki 2014-12-16 12 Domena główna (core domain)
13. • „Wszędobylski” język • Wypracowany z ekspertem domenowym • Ułatwiona komunikacja z klientem 2. Podstawowe składniki 2014-12-16 13 Ubiquitous language
14. Big Ball Of Mud – co z tym zrobić? 2014-12-16 14 2. Podstawowe składniki
15. • Modelowanie pojedynczej subdomeny • Subdomena -> ograniczony kontekst aplikacji • Praktyka: • Sytuacja idealna – odseparowane BC • Sytuacja praktyczna – współdzielenie obiektów 2. Podstawowe składniki 2014-12-16 15 BC1 BC2 Shared kernel Ograniczony kontekst (bounded context)
16. • Część wspólna aplikacji – np. autentykacja • Trudno zarządzalne – zespoły muszą uzgadniać zmiany w shared kernel • Z reguły rzadko zmieniana część kodu 2. Podstawowe składniki 2014-12-16 16 Shared kernel
17. Co jest najważniejsze? • Ekspert domenowy • Ubiquitous language • Core domain • Bounded context • Shared kernel 2. Podstawowe składniki 2014-12-16 17
18. Building blocks 2014-12-16 18
19. • Obiekty posiadające identyfikator • Obiekty zmienne • Encje anemiczne - antywzorzec • Metody biznesowe odzwierciedlają wyłącznie odpowiedzialności lub zachowania encji 3. Building blocks 2014-12-16 19 class AnemicClient { protected $id; protected $name; public function getId() { return $this->id; } public function setId($id) { $this->id = $id; } public function getName() { return $this->name; } public function setName($name) { $this->name = $name; } } class RichClient { protected $id; protected $firstName; protected $lastName; //.... public function changeName($newName) { .... } public function getFullName() { return $this->firstName . ' ' . $this->lastName; } } Encja (entity)
20. • Grupowanie encji • Główna jednostka logiki domenowej • Odzwierciedla zachowania systemu 3. Building blocks 2014-12-16 20 Aggregate Root Zamówienie Pozycja zamówienia 1 N Agregaty (aggregate)
21. • Obiekty, które posiadają atrybuty, ale nie mają identyfikatora • Value Objects są niezmienne (immutable) • Nadają prostym wartościom znaczenie biznesowe 3. Building blocks 2014-12-16 21 class Money { protected $amount; protected $currency public function __construct($amount, $currency) { $this->amount = $amount; $this->currency = $currency; } public function __toString() { return $this->amount . ' ' . $this->currency; } public function convertToCurrency($newCurrency) { //logika konwersji } } Value Object
22. • Funkcjonalności biznesowe nie pasujące do encji, agregatów i VO • Nie posiadają tożsamości ani cyklu życia • Są bezstanowe 3. Building blocks 2014-12-16 22 /** * Przykład serwisu domenowego * Może np. przekształcać jedne agregaty w inne * Operuje na logice domenowej */ class InvoicingService { /** * tworzy fakturę dla zamówienia */ public function createInvoice(Order $order, TaxPolicy $policy) { //logika domenowa: przetwarzanie Order w Invoice //często przy użyciu Policy returns $invoice; //agregat Invoice } } /** * Przykład serwisu aplikacyjnego * „Orkiestruje” obiekty i serwisy domenowe, * współpracuje z repozytoriami i innymi serwisami itd. * Opiera się o user stories. */ class PurchasingService { public function approveOrder($orderId) { //logika aplikacji: pobranie zamówienia z repozytorium, //sprawdzenie poprawności elementów zamówienia, //przypisanie należnego rabatu po zamówieniu, //wystawienie faktury za pomocą InvoicingService, //zapisanie wszystkich obiektów do repozytorium itp. } } Serwis
23. • Budowanie agregatów z półproduktów 3. Building blocks 2014-12-16 23 class OrderFactory { public function CreateOrder(Client $client) { if ($this->canHaveNewOrders($client)) { $order = new Order($client); return $order; } else { return false; } } protected function canHaveNewOrders(Client $client) { //sprawdzamy, czy klient może mieć nowe zamówienia } } Fabryka (factory)
24. Inne building blocks: • Repozytorium • Zdarzenie (events) • Polityka (policy) • Saga 3. Building blocks 2014-12-16 24
25. Co jest najważniejsze? • Agregat • Value object • Serwis domenowy • Serwis aplikacyjny 3. Building blocks 2014-12-16 25
26. Podsumowanie Używać czy nie? 2014-12-16 26
27. • Czas i wysiłek - izolowanie i modelowanie domen • DDD wymaga nauki – koncepcja, zasady, wzorce, procesy • Wyłącznie do złożonych zagadnień • DDD wymaga dostępności ekspertów domenowych • Blokady na poziomie organizacji Co nas powstrzymuje? 2014-12-16 27
28. • Elastyczny model i elastyczny kod – łatwość utrzymania i rozwoju • Realizujemy wizję klienta • DDD dostarcza sposobów na rozwiązanie bardzo trudnych problemów • Dobrze zorganizowany i łatwo testowalny kod • Ściśle wydzielona logika biznesowa A co zyskujemy? 2014-12-16 28
29. Domain driven-design jest trudny do opanowania i wdrożenia... Co jest najważniejsze? 2014-12-16 29 ...ale pomaga rozwiązywać trudne problemy i jednocześnie wspiera tworzenie uporządkowanego, testowalnego kodu, który łatwo jest utrzymywać
30. • E. Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software • C. Buenosvinos, Ch. Soronellas, K. Akbary: Domain-Driven Design in PHP • http://dddcommunity.org • http://www.bottega.com.pl/artykuly-i-prezentacje • http://williamdurand.fr/2013/08/07/ddd-with-symfony2-folder-structure-and-code-first/ • http://gorodinski.com/blog/2012/04/14/services-in-domain-driven-design-ddd/ Źródła wiedzy o DDD 2014-12-16 30
31. Dziękujemy bardzo! 2014-12-16 31
32. Krzysiek kkakol@pgs-soft.com Michał mkozlowski@pgs-soft.com www.pgs-soft.com