Nie ma jednej słusznej drogi

Różne podejścia do architektury systemów informatycznych

Michał Bartyzelmbartyzel.blogspot.com

@MichalBartyzel

ProblemyNaprawa co drugi miesiąc

Kilkukrotnie wymieniany

Liczba mieszkańców w klatce: 9 * 5 = 45

10 lokali * 3 osoby/lokal * 2 wciśnięcia/dzień = 60 osobowciśnięć/dzień

3 osoby * 2 wciśnięcia/dzień = 6 osobowciśnięć/dzień

NR LOKAL

U + KOD

DOSTĘPU

WnioskiObciążenie „5” co najmniej 10 razy większe

Z klawiszem „5” jest wszystko okArchitektura rozmija się z kontekstem użycia

Nowa wizja tego przypadkuNie używaj „5” w kodzie dostępuWprowadź więcej „5”

Nowa wizja architekturyNie używaj cyfry dziesiątek w kodzie dostępuWprowadź przycisk piętra

Nie ma jednej słusznej drogi

Rozwiązania architektoniczne są niezbędne

ale kontekst jest ważniejszy

Kilka przykładów

…ale działa?

…ale zarabia!

#1

DevCastZone.com

Zakup modułów szkoleń

Mikropłatności

Testy weryfikujące

Zabezpieczenia przed pobieraniem

Konta indywidualne

Konta firmowe

Pierwsza myślNapiszmy to sami w Javiejeeeeee! jupiii!

Po analizie kontekstu6 miesięcy

1 programistaPHP

#2

System K/P

Zarządzanie umowamiSystem zmianowyChoroby, zwolnienia, umowy, dodatkiHistoria zatrudnienia

Przeliczanie wypłat

PodpowiedźSystem stoi/stał na przeciętnym PCBrak zastrzeżeń dot. szybkości GUIRadził sobie z okresowymi „pikami”

PowerBuilder

To nie jest rozwiązanie uniwersalne

Tak nie trzeba robić

To jest rozwiązanie dla

tego kontekstu

Mały problem z nowoczesnością

#3

Gry

Robimy gry dla wielu klientówWłaściwie dla każdego klienta dana gra jest taka sama…ale trochę inna

Co zrobiłbydobrze wyedukowany

projektant/programista?

Co zostało zrobione?

Zatrudniamy wielu przeciętnych programistów

Dla każdego klienta piszemy od nowa

Utrzymujemy wiele wersji różnych systemów

Zamieniono problem inżynieryjny

na problem organizacyjny

To się nie musi udać każdemu

Tak nie trzeba robić

To jest rozwiązanie dla

tego kontekstu

Bo w innej galaktyce i innym kontekście…

Bo w innej galaktyce i innym kontekście…

Za dużo drobnych produktówZa dużo różnorodnych produktów

Za dużo klientówKoszt rozwoju zespołu przekracza zyskowność

#4

Instytucja państwowa

Obsługa wewnętrznych procesów w organizacji

Aplikacja dla klientów

5 osób60 zmian/projektDł. projektu: do 2 m-cyZawsze w niedoczasie

10 osób300 zmian/projektDł. projektu: do 2 m-cyZawsze na czas

Tam, gdzie architektura nie daje zbyt wielu możliwości….

nie ma również zbyt wielu dylematów

i okazji do popełniania błędów

Inni mieli z tym problemy

Tak nie trzeba robić

To jest rozwiązanie dla

tego kontekstu

#5

Przykładdla równowagi

Cache?Pomysł ok

Realizacja…hmm.

A potem już tylko gorzej

Technikalia przeniknęły do warstwy aplikacjiAutoHibernateBrak relacji obiektowychBrak relacji bazodanoywch

Konsekwencje

Zgubny brak

modelu

7 spraw, o których warto pomyślećzanim zaczniesz architekcić

Sprawa 1.

Biznesowy kontekst systemu

Sprawa 2.

Biznesowe przypadki zmian

Sprawa 3.

Biznesowy kontekst organizacji

Sprawa 4.

Potencjał kompetencyjny zespołu

Sprawa 5.

Analiza wpływu zmian

Sprawa 6.

Analiza systemu

Sprawa 7.

Czym jest Core Domain?

i na koniec dowód półformalny

No Free Lunch Theorem

Każda technologia, język czy metoda inżynierii oprogramowania…

jest jednakowo dobra dla ogółu problemów, z którymi się spotykamy

Jedyne, co może przesądzić o wyższości danego podejścia

to kontekst i różnice między kontekstami

Dlatego zanim powiesz XYZ jest zajefajne, tak róbmy…

Nie ma jednej słusznej drogi

Różne podejścia do architektury systemów informatycznych

Michał Bartyzelmbartyzel.blogspot.com

@MichalBartyzel

Użyte grafiki– https://encrypted-tbn3.gstatic.com/images?q=tbn:ANd9GcToe6mgA-dvsRs33PiEejM-

IDjlpAtWxS99PaePww7mxWAvyI5T– http://www.ekito.fr/people/wp-content/uploads/2013/01/gwt51.jpg– http://blog.toubiweb.com/wp-content/uploads/2013/04/java.gif– http://www.990px.pl/files/2009/08/2555555871404.jpg– http://www.multisoft.com.au/Images/OraFormsImg.jpg