Każdy kod ewoluuje. Duży produkt zaczyna jako małe niewinne MVP, by powoli i (oby) iteracyjnie rozrastać się do 'dorosłej' postaci. Równocześnie ze wzrostem produktu od strony 'ficzerów' rośnie jego wewętrzna komplikacja. Powstaje architektura - czasem zła, czasem dobra. Nowe API Getresponse'a jest gdzieś w trakcie tej drogi, juz po kilku iteracjach, juz nie jako MVP. Chciałbym podzielić się doświadczeniem z procesu budowania architektury naszego API, wyboru i implementacji rozwiązań architektonicznych oraz sposobu mierzenia efektywności naszych decyzji.

1. Ewolucja architektury
Getresponse API

2. Jak zacząć?
Pierwsza
iteracja
• Czas
• Łatwość implementacji
• MVP!

3. Architektura?
• Domena
• Zakres funkcjonalny
• Getresponse APP

4. Controllers
Services
Models / CoreApp
Framework
PHP Array’s
PHP Array’s

5. Problemy?
• Utrzymanie jednolitej struktury

8. Ok, wiemy co trzeba zrobić lepiej…
Druga iteracja
• REST Resource
• Kontrakt

9. Controllers
Services
Models / CoreApp
Framework
Resource Object
Resource Object

14. Problemy?
• Złamanie reguły SRP
• Skomplikowana konstrukcja obiektów,
• Brak separacji warstw

15. Trzeba to posprzątać
Trzecia iteracja
• Separacja warstwy
prezentacji
• Izolacja modeli
domenowych

16. Controllers
Services
Repository / CoreApp
Framework Command Query
Command Query Domain Entity
DTO
Resource Presenter

17. –Michał Giergielewicz
Dziękuję za uwagę
https://joind.in/16240
http://www.slideshare.net/michalgiergielewicz/ewolucja-architektury-getresponse-api