Service objecty dają nam sporo korzyści, ale nie rozwiązują problemów typowych dla dużych aplikacji Railsowych. Ta prezentacja podsumowuje pozostałe problemy oraz prezentuję docelową wizję opartą na DDD/CQRS.

1. Andrzej Krzywda, Arkency, from DRUG to PRUG with ❤ 2022
Service objecty to za mało
Jak żyć z Railsami?

2. Ruby w Polsce
jednoczmy się w Ruby User Groups

3. historia Ruby w Polsce

4. Z Railsami szybko się startuje

5. Optymalizacja pod dodawanie
nowych kolumn w bazie danych

6. Railsy optymalizują pod pierwsze
10 ticketów w Jirze

7. Potem mamy już
"zacementowany design"

8. Coupling everywhere

9. Mądrze wybieraj pierwsze 10
ficzerów

10. DHH mówi:
logika do modelów
oraz concerny

11. Community wybrało service
objecty

12. Ale każdy je robi po swojemu

13. I każdy je inaczej nazywa
commandy, serwisy, serwisobdżekty, usecase'y,
interactory, simplekomandy

14. Zaleta serwisów:
oddzielenie się od warstwy http railsów

15. Zwykle zostaje coupling do
ActiveRecord

16. Chociaż niektórzy opakowują
ActiveRecord warstwą repozytoriów

17. Serwisy i repozytoria
to taki etap serwisy+

18. Często też dochodzą takie wzorce
jak form object czy presenter pattern

19. I co dalej?
Czy etap serwisy+ nas zadowala?

20. Możnaby powiedzieć, że mamy
oddzielone app layer od frameworka

21. Ale nadal nie mamy domain layer

22. Czy eliminuje to couplingi?

23. Typowe problemy etapu serwisy+

24. Czy serwis może wywoływać
inny serwis?

25. Czy rozróżniamy nadserwisy i
podserwisy?

26. Czy prezentowanie danych (aka
query) to też serwis?

27. Czy dziedziczkonko serwisów
jest OK?

28. Czy wybieramy framework do
serwisów?

29. Czy mamy spójne zachowania
serwisów, czy mają stałe API?

30. Czy rzucamy wyjątki jak coś w
serwisie się nie powiedzie?

31. Czy używamy monady?

32. Gdzie szukamy odpowiedzi i
dlaczego tylko w świecie Rails?

33. Najważniejsze pytanie

34. Co chcesz w życiu robić?

35. aka
Co dalej?
Dokąd zmierzamy?

36. Do niedawna nie było tu łatwej
rady co dalej

37. Serwisy to gateway drug

38. Prawdziwa zabawa zaczyna się
jak sięgniesz po kolejne narkotyki

39. Te narkotyki to tak naprawdę rozbicie
serwis objectów na dalsze części
pierwsze - decoupling

40. Zapoznaj się jak wygląda świat
dużo głębiej

41. Rails+
DDD+CQRS+Events

42. Rails+
DDD+CQRS+Events
•To są uniwersalne metody, nic
wymyślonego tylko w świecie Ruby
•Sprawdzone w Java, .NET, PHP, Python
•Mamy dostęp do nich wszystkich z
dylematami

43. Rails+CQRS
Command Query Responsibility
Segregation

44. Rails+CQRS
Command Query Responsibility
Segregation
• Railsy idealnie pasują do podziału na odczyty i zapisy
• Odczyty to dedykowane zdenormalizowane "modele" per raport (read model)
• szybsze niż cache
• bez join'ów
• OrderList
• CustomerList
• Ledger
• Trudne do zaakceptowania dla Railsowca, bo:
• dużo denormalizacji danych
• DRY złamane
• Używamy ActiveRecord ale bez walidacji, callbacków itp
• Zapisy to komendy wysyłane do modułów biznesowych (DDD)

45. Domain Driven Design

46. Domain Driven Design
•Moduły biznesowe odzwierciedlające biznesowe działy
•Mówimy wtedy językiem biznesowym
•Nie ma tu zależności do frameworka
•Dużo duplikacji, bo:
•Order w każdym module znaczy co innego
•podobnie Customer
•podobnie Product
•Każda zmiana jest propagowana jako event, bo:
•inne moduły są tym zainteresowane
•eventy zastępują nam persistence (event sourcing

47. Event sourcing
•Odtwarzamy stan agregatów z krótkiej
listy eventów
•Pełna historia
•Minus:
•Trzeba nauczyć się radzić ze zmianą
schematu eventów (wersjonowanie)

48. Wiem, że nic z tego nie kumacie

49. poka kodzik

50. Arkency Ecommerce
https://github.com/RailsEventStore/ecommerce

51. nietrywialny projekt DDD + CQRS
+ Event Sourcing

52. Wskocz tam aby przekonać się
czy faktycznie to takie dobre

53. szybkie przejście przez UI

54. wrażliwych TheRailsWay'owców ostrzegam 😂
kodzik potencjalnie offensive

55. • Katalog z Rails nie jest root'em
• Równolegle "mamy" hanami
• Cała domena w ecommerce/

56. • Nie ma app/services
• app/models puste
• app/read_models

57. Controller actions - albo
komendy albo read model

58. Komendy to już świat domeny -
wejście/input do modułu biznesowego

59. Moduły biznesowe

60. Komendy to struktury danych

61. Command handler
to co pozostaje z service objectów

62. Agregaty - obiekty domenowe
pilnują przejścia stanów, to tutaj wpadają biznesowe
walidacje

63. Read modele
Dane, bez logiki

64. Read modele

65. Procesy biznesowe

66. Procesy biznesowe
Dyryguje procesami pomiędzy
działami biznesowymi

67. Procesy biznesowe

68. Dużo tego, ale warto

69. Małe moduły biznesowe

70. Małe read modele

71. Mega łatwo testowalne (in
memory)

72. Dużo deklaratywnego kodziku

73. Mało if'ków

74. Duża zgodność z biznesem

75. Performance!

76. Event log - łatwe debugowanie

77. Eventy - odtwarzanie systemu na
dzień konkretny

78. Gotowe klocki - RailsEventStore,
Event Browser, domeny, starter app

79. RailsEventStore

80. "Rails" tak trochę dla marketingu

81. zaprojektowany aby łatwo używać w
istniejących (legacy) Railsowych appkach

82. Pełne otestowanie domen
mutation testing!

83. Modular monolith
modulith
(no microservices, db transactions)

84. Wiadomo, gdzie "wkładać"
kodzik - oczywiste szufladki

85. Czy kogoś przekonałem, że
warto zajrzeć na to repo?

86. Arkency Ecommerce
https://github.com/RailsEventStore/ecommerce

87. https://blog.arkency.com
https://arkency.com/newsletter/
jeśli lubisz dostawać maile

88. Dzięki!