Dzisiaj wracam do C# (po dłuższej przerwie), chcę napisać pierwszy mały system ERP ( pracuje na tym w pracy ).
Poproszę Was o porady, od czego zacząć, każda wskazówka będzie cenna, jakiekolwiek tutoriale, książki, poradniki z których mógłbym korzystać.
Oczywiście pierwsze kilka dni poświęcę na solidną powtórkę podstaw, składni itp.
Zacznij od spisania tego co chcesz, żeby system robił, potem można podzielić to na historyjki, a do tego dopiero potem wymyślić architekture systemu. Gdy to będzie przemyślane, dopiero warto zacząć myśleć nad architekturą klas. Na samym końcu możesz zacząć myśleć o C# czy innym języku i kodzeniu. Do Odkrywania wymagań i tego jak mają iterakcje zachodzić warto chociaż w części zrobić diagram 4+1. W części bo też nie jestem fanatykiem mega projektowania, bo projekt ewoluuje w czasie, ale to narzędzie jest fajne do ogarnięcia całości. Nie myśl o bazie danych - pozostaw to jaką warstwe danych i użyj jakiegoś ORM, to nie przyjdzie Ci potem do głowy, żeby logikę w bazie osadzać. Zastanów się, też, wymagania jakie będą nie spowodują, że fajnie będzie zrobić mniej klasyczną architekturę (klient, serwer, dane), a może jakieś mikro serwisy, server less etc. Niemniej zacznij od zdefiniowania co aplikacja ma robić, bo samo pojęcie ERP jest za szerokie.
Ja bym polecił coś o ERP bo jak czytam "mały system ERP" to jakoś mi to nie brzmi. No bo co to jest "mały ERP"? Zamówienia bez produkcji i pracowników. Same magazyny? Tylko produkcja? Produkcja ale bez planowania materiałowego?
Kiedyś coś takiego czytałem(nie jestem pewien czy dokładnie to) i było sporo całkiem fajnych informacji o samej organizacji przedsiębiorstwa i modelowaniu.
Na pewno coś solidnego o architekturze systemu (DDD?) ale to już wyższa szkoła jazdy. Jeśli będziesz miał "moduły" w rodzaju Sprzedaż, Produkcja, Kadry itp to DDD jest (chyba) (prawie) zawsze dobrym pomysłem ale próg wejścia wysoki.
W miarę możliwości w ogóle nie myśl o bazie danych. Nie projektuj żadnych tabelek bo wyjdzie Ci TDD (Table Driven Design - to nie mój termin, zaczerpnięty z jakiegoś wykładu ale super słuszny). Myśl o procesach tak jak są realizowane przez ludzi. Temat rzeka. Sama umiejętność programowania to może z 15 - 20%.
Dla mnie bardzo ciekawe są wykładu Sławka Sobótki o architekturze. Poszperaj na YT, IMHO najlepszy w PL "opowiadacz".
Warto poszperać w sieci i poszukać jak wyglądają istniejące rozwiązania i co z nich chciałbyś zmieścić w swoim "małym ERP" bo może okazać się, że niekoniecznie jesteś omnibusem i wszystko wiesz, zauważasz. Mając już pewien zasób wiedzy łatwiej Ci będzie nie popełniać pewnych błędów. Warto przy tym pośledzić rozwiązania dedykowane dla danej branży, obszaru rynku bo zapewne będą tam specyficzne dla niej rozwiązania. Poza tym ERP to jedno a rzeczywistość i firma, która ma to wykorzystywać to drugie. Nie można przy pomocy ERP ogarniać chaosu panującego w firmie - tutaj potrzeba zmian w procesach firmy a z tym już nie zawsze da się coś zrobić. Wspomniane wcześniej "user stories" są dobrym sposobem na opisanie funkcjonalności. W ten sposób możesz "męcząc" doświadczonych pracowników, managerów itd uzyskać wiedzę jak powinien ich zdaniem wyglądać proces co ma duże znaczenie jeśli nie masz doświadczenia w danej domenie problemu.
Od czego zacząć - od początku :). Pogooglać, poszperać , pomęczyć YT a wszystko to z punktu widzenia gromadzenia informacji o ERP.