"Application Architecture for a Backend with Rich Business Logic – How to Ensure Maintainability?", Andrii Riabets.pptx

This presentation will focus on the maintainability quality attribute — how to keep business logic isolated, consolidated, encapsulated, and consistent, as well as how to integrate it with the infrastructure layer, including persistence, messaging etc.
All these aspects will be illustrated through a real-world task example and its implementation approach (code examples will be in .NET).

1. Backend with rich business logic - how to ensure Maintainability Автор: Андрій Рябець

2. Про що поговоримо?

3. Про що поговоримо?

4. Тематика

5. Infrastructure Performance Security Business logic Частка логіки в об’ємі робіт

6. Фокус

7. Складність читання і розуміння коду 1 Maintainability Складність/швидкість внесення змін 2 Ймовірність допустити помилку 3

8. Засоби досягнення

9. Інгредієнти

10. Uklon Контекст

11. Трилема DDD

12. ПОВНОТА 1 Обрані пріоритети КОНСИСТЕНТНІСТЬ ТА ІНКАПСУЛЯЦІЯ 2 ЧИСТОТА 3

13. Архітектура

14. IStorage - Unit Of Work трекає опубліковані доменні івенти зберігає агрегати конвертує агрегати в query model-і зберігає query model-і публікує підмножину доменних івентів назовні контексту, конвертуючи їх в інтеграційні

15. Persistence Command model - document-oriented approach in RDBMS природно лягає в концепцію агрегатів DDD тривіальне використання ORM природна одиниця для вирішення concurrency -конфліктів через optimistic strategy ACID доменна модель конвертується в окрему DAL-модель (гнучкіше - зміна моделі без міграції, обмеження ORM etc.) Query model - адаптовані read-проекції під необхідні запити Single transaction - агрегат та query model зберігаються в одній БД в рамках однієї транзакції дозволяє використовувати query model в command-сценаріях

16. Збереження Command Model

17. Конвертація в Query Model

18. Як досягти на прикладі реальної задачі - реєстрація приватного водія

19. Заявка на реєстрацію

20. Модель приватного водія

21. МОДЕЛЬ ПРИВАТНОГО ВОДІЯ Модель загалом складається з 4-ьох агрегатів : з користувача, який може виступати в кількох ролях з водія, який ідентифікується по номеру водійського посвідчення і може працювати в різних автопарках з авто, яке ідентифікується по держ номеру і VIN-коду та може переходити з парку в парк і врешті з автопарку, який має власника, водіїв-співробітників (з датами співробітництва) та автомобілів з періодом перебування в парку Приватний водій - частковий випадок автопарку з одним водієм, який одночасно є його власником, та одним авто

22. Use case-и на AppService

23. Логіка в агрегаті

24. Логіка в агрегаті

25. Інкапсуляція доменних івентів

26. Псевдохореографія

27. Псевдохореографія

28. Явна оркестрація

29. Підписка на доменні івенти

30. Інкапсуляція internal-методу

31. Декларація зовнішнього івенту

32. Реалізація на AppService-layer

33. Конвертація зовнішнього в доменний

34. Обробка в домені

35. Організація коду

36. ПІДСУМКИ

37. ПОВНОТА валідація (навіть проста по типу номера тел чи email) - теж бізнес-логіка авторизація - теж бізнес-логіка query -інг даних для перевірок та прийняття рішень - теж бізнес-логіка Виключення : реалізація методів в SpecificRepository -іях - логіка виконання запитів винесена в IStorage-адаптер

38. Інкапсуляція та консистентність валідація простих типів даних -в фабричних методах value object -ів здійснюємо авторизацію використання ReadOnly-колекцій в public -пропертях з інкапсуляцією модифікабельної колекції в полі не створюємо “дірок” для обходу інваріанту Domain Events має мати можливість створювати (і як наслідок - публікувати ) тільки сам агрегат-власник івента передачу управління по flow між агрегатами робимо за допомогою доменних івентів у випадку decoupled частин у flow якщо по доменному івенту має запуститись складний процес за участі кількох агрегатів, який потребує оркестрації: виділити явний доменний сервіс , який консолідує і зробить observable процес оркестрації відкрити методи, необхідні для цього оркестратора, тільки йому

39. Контрольовані порушення інкапсуляції public -метод static RestoreState для відновлення стану агрегату зі сховища методи встановлення контексту AppUser.SetCurrent(xxx) - встановлюється один раз при ініціалізації обробки запитів/повідомлень, по необхідності в юніт-тестах Publisher.SetInstance(xxx) - встановлюється один раз в контексті Unit Of Work, по необхідності в юніт-тестах public IIncomeExternalEvent : IDomainEvent - реалізувати інтерфейс і опублікувати івент може хто завгодно

40. Компроміси в ЧИСТОТІ для повноти IReadOnlyStorage для можливості query-інга даних з домену async/await в домені

41. Q&A