in polish

1. Domain Driven Design
!= Anemic Domain Model

2. Agenda
● Dlaczego projektowanie dziedziny jest ważne?
● Czym różni się od modelu anemicznego?
● OO i OOP oraz SOA zamiast pisania procedur.
● Ubiquitous Language.
● Bounded Context.
● Context Mapping i wzorce integracyjne.
● Core Domain.
● Architektura warstwowa i wzorce projektowe.
● Dependency Injection oraz Aspect Oriented Programming.

3. Projektowanie dziedziny
● Bardzo ważne przy tworzeniu złorzonego
oprogramowania.
● Obiektowy model dziedziny, posiada stan i
zachowanie.
● Rozwiązanie problemów złożoności.
● Modelowanie rozwiązywanego problemu.
● Odpowiedzialność we właściwym miejscu.
● DRY

4. Model anemiczny dziedziny
● Przerośnięta warstwa usług, zawiera całą logikę
biznesową.
● Trudna w utrzymaniu warstwa usług.
● Degradacja warstwy dziedziny.
● Przeniesienie korzyści na rzecz fasady.
● Ograniczenie możliwości testowania modelu.

5. Programowanie zorientowane
obiektowo
● OOP stworzone dla lepszego rozwiązywania
problemów.
● Zacierane przez niektóre technologie np. EJB, nie
ma obiektów mamy np. encje, beany.
● Wprowadzenie terminu POJO – zwykłe obiekty
języka Java.
● Często obsługa logiki sprowadza się do pisania
kodu procedur.

6. Ubiquitous Language
● Tworzony w czasie rozmów z klientem.
● Wspólny język dla dziedziny, wynika z analizy.
● Wspólny język projektu dla projektantów,
programistów zaczerpnięty z żargonu świata
rzeczywistego.

7. Związany kontekst
● Każdy model ma swój kontekst.
● Integralność modelu.
● Jest logiczną ramą rozwijanego modelu.
● Pojedyńczy model łatwiej zarządzany przez jeden
zespół.
● Każdy związany kontekst powinien mieć nazwę
ze wspolnego języka opisu.

8. Mapa kontekstu

9. Mapa kontekstu cd.
● Shared Kernel
● Customer-Supplier
● Conformist
● Separate Ways
● Open Host Services
● Anticorruption Layer

10. Mapa kontekstu cd.
● Shared Kernel oraz Customre-Supplier to
wzorce dajace wysoki stopien interakcji pomiedzy
kontekstami.
● Separate Way może być stosowany jeśli chcemy
by konteks był odseparowany i rozwijany
oddzielnie.
● Open Host Service oraz Anticorruption Layer
w przypadku interakcji z zewnetrznymi
systemami.

11. Mapa kontekstu cd.
Shared Kernel

12. Mapa kontekstu cd.
Shared Kernel
● Redukuje duplikacje, ale w dalszym ciągu
utrzymuje odseparowane konteksty. Wymaga
uwagi gdyż różne zespoły modyfikują rdzeń.
● Testy oraz Continuous Integration.

13. Mapa kontekstu cd.
Customer-Supplier
● Jeśli jeden podsystem zalerzy mocno od innego.
● Rezultat procesu jest przekazywany do
podsystemu.
● Zespoły są mocno zainteresowane wzajemną
relacją tworzonych podsystemów.
● Dostawca powinien wspierać klienta.

14. Mapa kontekstu cd.
Conformist
● Podobnie jak w przypadku wzorca Shared Kernel,
jednak bez możliwości dokonywania zmian.
● Jeśli używanykomponent ma złorzony interfejs,
używane w modelu jako własny.
● Jeśli komponent ma niewielki interfejs, warto
zastanowić się nad adapterem do translacji
pomiędzy naszym modelem a modelem z którego
komponent się wywodzi.

15. Mapa kontekstu cd.
Anticorruption Layer
● Jeśli integracja przez protokół komunikacyjny,
lub przez bazę danych.
● Brak informacji o modelu, dostępne są
prymitywne dane.
● Istnieje ukryta semantyka danych.
● Potrzeba izolacji modelu od systemu
zewnętrznego.

16. Mapa kontekstu cd.
Anticorruption Layer
● Warstwa komunikuje się z zewnętrznym
modelem wykorzystując zewnętrzny język.
● Spełnia formę dwu kierunkowego translatora
pomiędzy dziedzinami i językami.
● Service jako fasada z zastosowaniem adaptera.

17. Mapa kontekstu cd.
Anticorruption Layer

18. Mapa kontekstu cd.
Separate Ways
● Jeśli jest pewność że można podzielić aplikację na
kilka mniejszych niezależnych od siebie aplikacji.

19. Mapa kontekstu cd.
Open Host Service
● Jeśli podsystem ma się integrować z różnymi
klientami i trzeba tworzyć warstwę translacji dla
każdego.
● Potrzeba utworzenia jednego protokołu
komunikacji reprezentującego przeźroczystą
grupę usług.

20. Mapa kontekstu

21. Core Domain
● Po pierwsze wyszukanie i zdefiniowanie głównej
domeny projektu jako najbardziej priorytetowej.
● Zaniedbania w tej części mogą stać się
katastrofalne dla systemu.
● Podporządkowanie innych części jako wsparcie.

22. Core Domain cd.
Generic Subdomains
● Istotne dla funkcionowania systemu i pełnego
wyrażenia modelu.
● Identyfikowanie spójntch poddomen, które jednak
nie są motorem działania systemu.
● Osadzanie w osobnych modułach.

23. Architektura warstwowa.
● Interfejs użytkownika - prezentacja i interpretacja poleceń
użytkownika.
● Warstwa aplikacji - koordynuje czynności aplikacji. Nie zawiera
logiki bienzsowej ani stanu obiektów biznesowych. Zachowuje
stan zadań.
● Warstwa dziedziny – serce aplikacji, zarządza informacją o
dziedzinie. Stan obiektów biznesowych. Utrwalanie obiektów w
warstwie infrastruktury.
● Warstwa infrastruktury – jest wsparciem dla innych warstw.
Dostarcza komunikację między warstwami, implementuje
utrwalanie obiektów, zawiera dodatkowe wsparcie dla interfejsu
użytkownika.

24. Wzorce projektowe
● Implementacja modelu, też może zawieść.

25. Wzorce projektowe cd.
● Entities
● Value Objects
● Services
● Aggregates
● Factories
● Repositories

26. Wzorce projektowe cd.
Entities
● Posiadają tożsamość.
● Nie zmieniają stanu.
● Są to instancje trzymane w pamięci.
● Referencja spełnia warunek tożsamości.
● Kombinacja unikalnych atrybutów.
● Konieczny obiekt w modelu dziedziny.

27. Wzorce projektowe cd.
Value Objects
● Nie posiada tożsamości.
● Ważne są atrybuty.
● Ułatwia to tworzenie obiektów i zwalnianie.
● Powinny być immutable (tworzone przez
konstruktor i niemodyfikowalne).
● Mogą być współdzielone, zachowują integralność
danych.
● Mogą zawierać inne obiekty VO lub referencje do
Entity.

28. Wzorce projektowe cd.
Services
● Nie wszystkie aspekty domeny mogą być
mapowane do obiektów.
● Jeśli akcja nie jest w zasięgu obiektu.
● Nie posiada wewnętrznego stanu.
● Grupuje funkcionalność dla wielu obiektów.
● Interfejsy dostarczające operacje wewnątrz
konceptu dziedziny.
● Operacje są bezstanowe.

29. Wzorce projektowe cd.
Aggregates
● Należy do cyklu życia obiektu domeny.
● Określa właściwości obiektu i jego granice.
● Asocjacje one-to-one, one-to-many, many-to-
many.
● Bidirectional ale samochod ma silnik.
● Aggregates posiada jednego roota – Entity
(jedyny obiekt widziany z zewnątrz)

30. Wzorce projektowe cd.
Factories
● Tworzą złorzone czasem struktury Encji I
Agregatów.
● Proces musi być atomowy tak aby obiekty były
we własciwym stanie.

31. Wzorce projektowe cd.
Repositories
● Baza danych jest częscią infrastruktury.
● Może przetrzymywać referencje do obiektów.

32. Wzorce projektowe

33. ●
Dependency Injection
public class MoneyTransferServiceImpl implements MoneyTransferService {
● private final AccountRepository accountRepository;
● private final BankingTransactionRepository bankingTransactionRepository;
● @Autowired
● public MoneyTransferServiceImpl(AccountRepository accountRepository,
● BankingTransactionRepository
● bankingTransactionRepository) {
● this.accountRepository = accountRepository;
● this.bankingTransactionRepository = bankingTransactionRepository;
● }
● public class HibernateAccountRepository
● implements AccountRepository {
● private HibernateTemplate hibernateTemplate;
● @Autowired
● public HibernateAccountRepository(HibernateTemplate template) {
● hibernateTemplate = template;
● }
● }

34. Dependency Injection
● <beans>
● <context:annotation-config/>
● <bean name="moneyTransferService" class="MoneyTransferServiceImpl"/>
● <bean name="accountRepository" class="HibernateAccountRepository"/>
● </beans>

35. AOP
● <bean id="authorization.loggingListener" class="...impl.listener.LoggingListener" />
● <bean id="authorization.ConnectionAdvice" class="...impl.listener.ConnectionAorund">
● <property name="Listeners" >
● <list>
● <ref bean="authorization.loggingListener" />
● </list>
● </property>
● </bean>
● <aop:config>
● <aop:pointcut id="authorization.ConncetionPointcut" expression="execution(*
...impl.helper.TopUpConnection.*Invocation(..))" />
● <aop:aspect id="authorization.ConnectionAspect" ref="authorization.ConnectionAdvice">
● <aop:around method="around" pointcut-ref="authorization.ConncetionPointcut"/>
● </aop:aspect>
● </aop:config>

36. AOP
● public Object around(ProceedingJoinPoint call) throws Throwable {
● for(Listener listener : listeners) {
● notify(listener, call, null);
● }
● Object result = call.proceed();
● for(Listener listener : listeners) {
● notify(listener, call, result);
● }
● return result;
● }

37. Literatura
● Domain-Driven Design: Tackling Complexity in the
Heart of Software – Eric Evans
● Patterns of Enterprise Application Architecture –
Martin Fowler
● http://domaindrivendesign.org
● http://martinfowler.com