Językiem biznesu nazywamy ogół słownictwa używany przez różnych ekspertów domenowych. Język ten powinien być w pełni transparentny i jednoznaczny. Posługiwanie się takim językiem wiąże się z licznymi korzyściami. Wśród nich można wymienić sprawniejszą komunikację, większe zrozumienie problemów, ułatwienie współpracy pomiędzy zespołami, zacieśnianie więzów w firmie czy ułatwiony proces pisania testów.

Pewnie już spotkałeś się z takimi określeniami jak logika biznesowa oraz logika aplikacji. Na podstawie własnego doświadczenia zauważyłem, że programiści bardzo często operują terminami logika biznesowa i logika aplikacji ale nie zawsze rozumieją jakie jest ich znaczenie lub, co gorsza, używają ich zamiennie. W tym wpisie wyjaśniam co kryje się pod tymi pojęciami i podaję kilka przykładów, które powinny Ci pomóc w poprawnej klasyfikacji logiki.

Często wybór języka wysokopoziomowego powoduje że siedzimy tylko i wyłącznie w software, a w sprzęt się nie zagłębiamy. Natomiast elektronicy, automatycy oraz programiści niskopoziomowi mają zazwyczaj bezpośrednią styczność z hardware, a co za tym idzie najczęściej znają się na oprogramowaniu CAD. Ale co zrobić, gdy nagle okaże się że musimy na szybko coś narysować, a nie mamy doświadczenia w użytkowaniu zaawansowanego oprogramowania CAD?

Spodobała mi się sama nazwa „Onion Architecture” jak i to co pod tą nazwą przedstawił Jeffrey Palermo. Niby zasady znane od dawna, a jednak zostały one umiejętnie pokazane na nowo. Niestety na sieci ciężko znaleźć szkielet przykładowej aplikacji, która spełniała by podstawowe założenia. W związku z tym na szybko zmontowałem takowy.

Od jakiegoś czasu myślałem o zebraniu w garść przemyśleń związanych z rozwojem projektów, bazując na doświadczeniach w aplikacjach, przede wszystkim biznesowych, w produkcji których przyszło mi uczestniczyć. Ponieważ pamięć jest zawodna i nie wszystko co chciałem wymienić udało mi się spamiętać i ubrać w słowa...

Jestem właśnie w trakcie lektury "Czystego kodu" Roberta C. Martina (polecam wszystkim programistom). Chciałbym podzielić się pewnym spostrzeżeniem autora tej książki. Otóż jako zupełne przeciwieństwa stawia on kod obiektowy oraz kod proceduralny operujący na strukturach danych. Zasadnicza różnica polega na tym, że klasy ukrywają swoją implementację komunikując się ze światem zewnętrznym wyłącznie przez metody, podczas gdy struktury danych mają zupełnie jawną postać, przez co nie potrzebują żadnych metod...

Nie spodziewajcie się długiego postu, krótko i na temat. Ostatnio w moje ręce wpadł projekt, którego jak kod zobaczyłem to nap oczątku złapałem się za głowę a potem przez pół dnia się z niego śmiałem. Nawet nie chodzi o to, że design był zły, choć do najlepszych on nie należy ale ten temat pominę. Chodzi raczej o nazewnictwo użyte w projekcie.