Document Oriented Programming, SOA

Wstępniaczek

Tak żebym nie zapomniał, kilka uwag co do całości. Ktoś może zadać pytanie: po co to Document Oriented Programming? Kiedy konkrety bo na razie lejesz wodę? Konkrety będą przedstawiane sukcesywnie z każdą kolejną notką – be patient, mam też swoje życie (jeszcze). Druga uwaga, która dotyczyć będzie aktualnego odcinka (tu trochę dłużej): “obiecałem” taką a nie inną formę wpisu, jednak chyba sobie daruje. Doszedłem do wniosku, że nie ma sensu szczegółowo porównywać programowania komponentowego i SOA – jeżeli ktoś jest rozgarnięty powinien sam sobie dopowiedzieć (doczytać na guglu) czym jest programowanie komponentowe, jakie były założenia paradygmatu a jak to wygląda dzisiaj (chodzi mi o rozbieżności, a trochę ich jest). Skupię się natomiast na architekturze zorientowanej na usługi w celu pokazania, jak wiele wnosi ona do procesu tworzenia oprogramowania, czemu warto zapoznać się z charakterystyką SOA i w jaki sposób SOA ułatwia usystematyzowanie procesów myślowych (nie święci garnki lepią).

Document Oriented Programming, wprowadzenie

Teraz będę nudził. Niemiłosiernie. Dobija mnie sposób, w jaki dzisiaj tworzy się oprogramowanie. Nudne jak flaki z olejem, naprawdę nie wiem, jak Wy to wytrzymujecie (tak tak, to do Was programiści). Jak długo można powielać ten sam kawałek kodu?? Czy tylko ja mam ochotę pokazać publicznie jakiego kotleta jadłem wczoraj? Czym to jest powodowane (nie mam na myśli kotleta)? Nie wiem … Ale chyba znalazłem przepis jak to zmienić. Wpis ten jest początkiem serii notek, które będą opisywały alternatywne podejście do programowania czegokolwiek, bez względu na specyfikę aplikacji oraz jej wymagania biznesowe/inne. No ale pod początku …