Czy powinienem organizować moje foldery według domen biznesowych czy technicznych?

Na przykład, jeśli korzystam z architektury podobnej do MVC, jakiej struktury folderów powinienem użyć:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

Lub:

controllers/
    domain1
    domain2
models/
    domain1
    domain2
views/
    domain1
    domain2

Celowo pominąłem rozszerzenia plików, aby utrzymać to pytanie bez względu na język.

Osobiście wolałbym rozdzielać według domen biznesowych (przeczucie), ale widzę, że większość / wiele ram oddzielnych według dziedzin technicznych. Dlaczego miałbym wybierać jeden nad drugim?

Myślę, że to zależy od konkretnego projektu.

Na przykład, jeśli różne domeny biznesowe są całkowicie od siebie niezależne, organizowałbym według domen biznesowych.

Jeśli jednak istnieje wspólny kod między domenami biznesowymi, a raczej domeny biznesowe to różne warianty tej samej bazy kodu, logiczne wydaje się organizowanie według domen technicznych. A jeśli używasz dowolnego języka obiektowego, prawdopodobnie możesz podklasować ogólne kontrolery, modele itp. W plikach biznesowych, aby były cieńsze.

Między nimi jest również (złoty) środek - usuń wspólny kod do jego własnej domeny i użyj go w innych domenach. Daje to układ oparty na przeczuciach, ale pozwala na udostępnianie kodu między domenami biznesowymi.

Domain1              # This domain changes bits of standard MVC code
  controllers
  models
  views
Domain2              # this domain only modifies views, all else is standard
  views
Shared               # Here is the better part of code base
  controllers
  models
  views

PS. Myślę, że większość frameworków organizuje się według domen technicznych tylko dlatego, że zwykle oczekują, że zmieszasz różne domeny biznesowe w jeden projekt tylko wtedy , gdy masz wspólny kod, a w przeciwnym razie stworzysz osobne projekty.

EDYTOWAĆ:

Załóżmy na przykład, że istnieje aplikacja internetowa, która obsługuje magazyn firmy. W ogólnej formie może to dotyczyć wielu firm, ale każda z nich może mieć pewne niespełnione szczegóły i zabrania ich zakupu. Np. Jedna z nich wdrożyła tablety do wózków widłowych i potrzebuje specjalnego widoku dla nich, a jeszcze inna chce organizować przedmioty na trzy poziomy zamiast domyślnych dwóch.

Oczywiście możesz rozwidlić projekt dla każdej z tych firm. Ale jeśli pozwala na to środowisko / język, możesz użyć podklasy lub wtyczek itp., Aby dostosować części ogólnego projektu do potrzeb każdego klienta i uporządkować je w układach Domeny Biznesowej.

Np. Jeśli ogólny projekt eksportuje do JSON tylko sam element, Domena 1 może podklasować kontroler i sprawić, że eksportuje również ostatnie problemy z dostawą.

A jeśli później okaże się, że Domena 1 ma składnik, który jest również ważny dla Domeny 2, możesz wyodrębnić jego ogólną wersję do Udostępnionego.

Jak powiedziałeś, wiele frameworków organizuje się według dziedzin technicznych i właśnie z tego korzystałem, tylko dlatego, że mój FW ułatwia to. Ale przy odrobinie (lub dużo) smaru łokciowego myślę, że mógłbym przepisać ścieżki dołączania, aby obsługiwały również układ domeny biznesowej.

Myślę, że dobrze jest zapytać: „co częściej dodam regularnie, więcej domen lub więcej podziałów technicznych?” Zatem bez względu na odpowiedź umieść to na najwyższym poziomie.

W większości przypadków twoja architektura techniczna krzepnie szybciej niż domena. Oznacza to, że należy najpierw uporządkować według domeny, a następnie według komponentu architektonicznego. Powodem jest to, że gdy coś w domenie zmienia się, może być konieczne dodanie lub zmiana wielu technicznych składników w tej domenie, ale mam nadzieję, że jest to zlokalizowane i nie rozlewa się zbytnio na inne domeny.

Jeśli zmieniłeś strukturę GUI, oznacza to, że zmiany zostaną rozlane na całą aplikację, ale z drugiej strony rzadko zmieniasz strukturę GUI, ale zawsze zmieniasz logikę domeny.

Trzymaj rzeczy razem, jeśli mogą się zmienić w tym samym czasie.

Istnieje inna alternatywa, która polega na przenoszeniu oddzielnych części we wtyczkach. CakePHP robi to na przykład. Pozwoli ci to wygenerować kompletne części MVC, które nadają się do ponownego użycia, które możesz sortować według dowolnej logiki.

Twoja główna aplikacja po prostu z nich skorzysta i połączy się z nimi.

Zasadniczo twoje pytanie dotyczy także spójności i sprzężenia. Chcesz, aby oddzielne części działały tak niezależnie, jak to możliwe. W ten sposób otrzymujesz testowalny i wielokrotnego użytku kod.

Biorąc to pod uwagę: jeśli podzielisz według domen, w jaki sposób ponownie wykorzystasz części aplikacji? Na przykład weź sklep internetowy: przychodzi prośba o / zamówienia / widok / 1, więc musisz pokazać nr zamówienia. 1. Przechodzi do / zamówień / kontrolerów / order_controller Jeśli oddzielisz domenę według produktów i zamówień, już potrzebujesz części innej „domeny”.

Tam możesz zacząć interfejsować rzeczy, ale prawdopodobnie rzeczy są w większości firm po prostu zbyt spójne. Jeśli zastosujesz podejście techniczne. Na przykład możesz mieć wtyczki obsługujące zamówienia. Umieszczasz w nim obiekty produktu z centralnej aplikacji. W ten sposób możesz łatwo przetestować wtyczkę, po prostu stwórz obiekt Product o nazwie i cenie i wyślij go.

Wtyczka zrobi dokładnie to, co powinna. Będzie to zależeć od jego danych wejściowych, a nie od innych „części / domen / obszarów”.

Microsoft ASP.Net MVC 3 ma pojęcie „Obszary”. Kiedy wprowadzasz „Obszary” do swojego projektu MVC, dzielą je one w następujący sposób:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

Uważam, że jest to całkiem naturalne. Obszar to „duża część” projektu, a praca w samodzielnej jednostce miała sens.

Użyliśmy przestrzeni nazw, aby dopasować, FWIW.

Z mojego osobistego doświadczenia w sklepie internetowym składającym się z 300 000 linii kodu zawsze wybierałem organizowanie według domen biznesowych. W ten sposób możesz nie tylko uzyskać szybki przegląd wszystkich odpowiednich klas podczas pracy w jednym obszarze funkcjonalnym, ale w Javie możesz również korzystać z widoczności pakietu.

Kilka szczegółów dla zainteresowanych: Gdy projekt został rozpoczęty 5 lat temu, programiści stworzyli następującą strukturę pakietów:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Każda funkcja sklepu, taka jak koszyk, wyszukiwanie produktów itp., Składa się z kilku akcji, każda z własną klasą formy (struktura wymagana przez środowisko MVC). Skończyło się na tym, że w pakiecie akcji znajduje się ponad 200 klas, z których każda jest całkowicie oddzielona od powiązanej z nimi klasy formularza. Co gorsza, działania nie implementują zbyt dużej logiki, ale wywołują usługi specyficzne dla funkcji, które znajdują się w jeszcze innym pakiecie.

Zasugerowałem i przekonałem zespół, że powinniśmy przejść na organizowanie pakietów według domen biznesowych. Rozumowanie jest proste: jeśli naprawdę chcesz zobaczyć listę wszystkich akcji, możesz po prostu otworzyć widok hierarchii typów dowolnego przyzwoitego IDE. Jednak to, czego IDE nie może zrobić, to wywnioskowanie domeny biznesowej, do której należy klasa. Co więcej, takie podejście pozwala upublicznić tylko te klasy, które są potrzebne przez kilka funkcjonalności, a resztę pozostawia widoczność pakietu.

Zgadzam się, że wiele frameworków jest oddzielnych według dziedzin technicznych, dlatego często zaczynam w ten sposób, kiedy używam nowego frameworka. Jednak konsekwentnie używam domeny biznesowej jako podstawowego poziomu organizacji folderów.

Osobiście uważam, że o wiele łatwiej jest trzymać mój kontroler Foo i repozytorium Foo lub cokolwiek innego razem niż przechodzić do przodu i do tyłu między folderem kontrolera a folderem repozytorium, ponieważ często muszę pracować nad obydwoma, dodając funkcje wokół Foo. W większych projektach jest to jeszcze ważniejsze, ponieważ odległość między folderami technicznymi może być duża i stać się zauważalną stratą czasu podczas opracowywania.