1. Domain-Driven Design Programowanie przez modelowanie

2. O mnie Bloguję: Simon-Says-Architecture.com Twittuję: www.twitter.com/SzymonPobiega Koduję: DDDSample.Net, Ncqrs, NetMX Prezentuję Prowadzę szkolenia Pracuję

3. Założenia Mówimy o systemach informatycznych klasy enterprise Systemy te przechowują swoje dane w (jakiejś) bazie danych

4. Model

5. Rozwiązujemy problem Problem (wymagania) Rozwiązanie (kod)

6. Modelujemy problem Problem (dziedzina) Model (kod) Problem (wymagania) Rozwiązanie (kod)

7. Jaki powinien być model? Użyteczny Hermetyczny Podatny na modyfikacje Testowalny Zrozumiały dla wszystkich interesariuszy Wydajnie implementowalny

8. Jaki nie powinien być model? Uniwersalny Zależny od technologii Zamrożony

9. Bez modelu Krok 1 Krok 2 Krok 3 Aplikacja

10. Bez modelu Aplikacja Testy integracyjne

11. Model Krok 1 Krok 2 Krok 3 Aplikacja Model

12. Model Testy persystencji Testy jednostkowe Aplikacja Model

13. DEMO Umacnianie modelu

14. Meta-model Ponieważ każdy model ma swój model

15. Wzorzec Domain Model Zawiera wiele Entity Aggregate Posiada jeden Jest Zawiera ValueObject Aggregate Root

16. Prosty workflow Proces Składa się z wielu Generuje Zdarzenie Czynność Aktywuje

17. Meta-model Wprowadza uporządkowanie Model to kwestia projektowa, meta-model zaś – architektoniczna Istnieją gotowe meta-modele, takie jak wzorce z grupy Domain Model

18. DEMO Meta-model

19. Podsumowanie Lepsze zrozumienie Możliwość powtórnego użycia (koncepcji) Pozytywny wpływ testowalność Zwiększona wydajność Większy koszt początkowy Trudne 

20. Dziękuję za uwagę