[Zarządzanie projektami] Podział semantyczny czy dziedzinowy?

Chciałbym zapytać się jaki podział wy stosujecie oraz jakie zalety/wady widzicie w obu rozwiązaniach. Być może temat wydaje się enigmatyczny toteż przybliżę go przykładem:

Może:

Czy może:

W przypadku pierwszego podziału nie podoba mi się dość nieintuicyjne ukazanie przepływu natomiast w drugim pojawia się problem "rzeczy, które nigdzie nie pasują" czy też wielu domen po jendnym pliku, które chciałoby się upchnąć w jakimś worku. Rozwiązanie hybrydowe wydaje mi się "brudne" oraz problematyczne w utrzymaniu oraz subiektywne w uznaniu co wrzucić w strukturę domenową a co w semantyczną.

To zależy co chcesz osiągnąć. Ja mam wypracowany własny sposób organizacji projektów na bazie n-letniego doświadczenia. Problemy, które musisz rozwiązać:
1. Biblioteki 3rd-party - ich kompilacja i dostępność w różnych projektach
2. Biblioteki własne, a ich wygodne współdzielenie z innymi projektami
3. Aplikacje własne.
4. Rosnąca liczba solucji.
5. Własne źródła nie mają być wymieszane ze źródłami 3-rd party (bo jak ktoś chce grepować to zazwyczaj nie chce tego robić po źródłach 3rd-party).

Później dopiero dochodzi standaryzacja w obrębie biblioteki, którą chyba u Ciebie można zauważyć.

Jedno czym mogę na pewno się podzielić to unikanie tworzenia nadmiernej liczby bibliotek. Przykładowy podział bibliotek:
1. core - biblioteka narzędzi podstawowych, które nie wymagają korzystania z jakiegokolwiek 3rd-party
2. wrappers - biblioteka, która dostarcza wygodne wrappery, zapewniające crossplatformowość. Tylko w tym miejscu mogą występować ifdefy związane z systemem operacyjnym/kompilatorem.
3. common - biblioteka, która wymaga core lub wrappers, aby zbudować jakieś uniwersalne narzędzie.
4. graphics - biblioteka dostarczająca narzędzia graficzne
5. gui - biblioteka dostarczająca cały silnik GUI i kontrolki
6. network - biblioteka dostarczająca narzędzia sieciowe

Kolejne 'uniwersalne' biblioteki można tworzyć, jednak ten poziom szczegółowości jest wystarczający do pokrycia większości potrzeb. Jeżeli znajdzie się osobna dziedzina, która ma dużo zagadnień to po prostu dorabiasz osobną bibliotekę na daną dziedzinę. Np grafy są dużą dziedziną ze sporą ilością algorytmów, więc kolejną biblioteką do tego zestawu jest 'graph'.

Potem pojawia się jeszcze dziedzina bibliotek związanych z danym projektem. Przykładowo:
1. appWorms - aplikacja/gra
2. libWorms - biblioteka zawierająca zdecydowaną większość kodu appWorms
3. tstWorms - zbiór testów jednostkowych testujących wybrane funkcjonalności libWorms

Do tego pojawia się fakt, że zazwyczaj ma się więcej niż jeden projekt, więc... w praktyce musisz zorganizować:
1. Biblioteki 3rd-party
2. Biblioteki uniwersalne własne
3. Biblioteki dedykowane do własnych projektów
4. Aplikacje własne
5. Testy jednostkowe do bibliotek z projektów własnych i bibliotek uniwersalnych

Finalnie celem jest osiągnięcie stanu, w którym rozpoczęcie pracy z nowym projektem jest proste, szybkie i ustandaryzowane.

Dzięki za garść informacji. Biblioteki i zależności to oczywiście temat rzeka, bardziej miałem na myśli organizacje wewnątrz własnego modułu.

Naturalnie nie chciałbym mieszać klas z zewnętrznych bibliotek i własnych, po prostu myślę nad wewnętrzną organizacją we własnym module. Mam kilkanaście klas, modeli, parserów, fabryk i nie wiem w jaką strukturę je ułożyć. Aktualnie używam tej pierwszej, ale chciałbym poszukać czegoś bardziej optymalnego bo zaczyna mi się ciężko żyć z aktualną strukturą.

A nie chciałbym też refaktorować całej struktury aby potem wycofać zmiany :)

Doświadczenie mówi, że najwygodniej mieć listę płaską w katalogu ze źródłami dla jednej biblioteki. Czyli:
Sztuczną hierarchizację umożliwia Visual Studio, a przebijanie się przez n-warstw katalogów nie jest zbyt wygodne.

Opcjonalnie: zobacz sobie jak SFML zorganizował swoją bibliotekę. Tam jest to całkiem znośnie.