Nie ulega wątpliwości, że Visual Studio jest jednym z najlepszych jak nie najlepszych IDE dostępnych na rynku. Jednak płaci on za to wielką cenę - wydajność i elastyczność. Czy my programiści .NET jesteśmy skazani na VS? Czy istnieje dla nas alternatywa? Na te i inne pytania znajdziecie odpowiedź na sesji

Ciężko zliczyć wszystkie metody, praktyki, podejścia i metodyki dotyczące tworzenia kodu, jego testowania a nawet zarządzania całymi projektami IT. Ale wszystkie one skupiają się generalnie albo na stronie czysto technicznej albo mocno zarządczej, ślizgając się zupełnie wokół kwestii związanych z projektowaniem i modelowaniem. Faza "dizajnu" nie doczekała się żadnych podejść formalnych, no może poza mniej lub bardziej ułomnymi (i chyba już odchodzącymi już do lamusa) notacjami typu UML albo BPMN.

Chlubnym (?) wyjątkiem od tej reguły jest "Domain Driven Design" - podejście do tworzenia oprogramowania w oparciu o tzw. modele domenowe. Jego twórca i główny popularyzator, Eric Evans, twierdzi że dzięki wprowadzeniu zaproponowanych przez niego reguł i pojęć, tworzone programy bardziej odpowiadają wymaganiom odbiorców, lepiej odwzorowują te najbardziej skomplikowane scenariusze biznesowe i są łatwiejsze w późniejszym rozwoju i utrzymaniu. Patrząc na lawinowo rosnącą popularność DDD, wygląda na to, że coś w tym jest ...

Celem mojej prezentacji jest zapoznanie Was z podstawowymi regułami i pojęciami DDD oraz podzielenie się własnymi spostrzeżeniami, na podst. doświadczeń projektowych z wykorzystaniem DDD.

Agenda:

1.) Designu jeden grzech główny

2.) Jak to zwykle robimy i co złego z tego wynika :)

3.) Czym DDD jest, a czym nie jest

4.) Podstawowe pojęcia i "building blocks" w DDD

5.) DDD w praktyce - "the warstory" + garść wniosków

6.) Gdzie szukać dalej - źródła wiedzy i przykładów