Klasörlerimi işletme alanına veya teknik alana göre mi düzenlemeliyim?

Örneğin, MVC benzeri bir mimari kullanıyorsanız, hangi klasör yapısını kullanmalıyım:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

Veya:

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

Bu soruyu dile agnostik tutmak için kasıtlı olarak dosya uzantılarını bıraktım.

Şahsen, işletme alanına (bağırsak hissi) göre ayrılmayı tercih ederim, ancak çoğu çerçevenin teknik alana göre ayrıldığını görüyorum. Neden birini diğerinden seçmeliyim?

Bunun özel projeye bağlı olduğunu düşünüyorum.

Örneğin, farklı işletme alanları birbirinden tamamen bağımsızsa, işletme alanına göre organize olurdum.

Ancak, iş alanları arasında paylaşılan kod varsa veya daha doğrusu, iş alanları aynı kod tabanının farklı varyantlarıysa , teknik alana göre düzenlemek daha mantıklı görünüyor. Herhangi bir Nesne Odaklı dil kullanırsanız, genel denetleyicilerinizi, modellerinizi vb. İşletmenize özgü dosyalarınızda daha ince yapmak için alt sınıflandırabilirsiniz.

Ayrıca, iki - paylaşılan kodu kendi etki alanına ayırın ve bunu diğer alanlarda kullanın (altın). Bu size bağırsak hissi ile çalışan düzeninizi verir, ancak iş alanları arasında paylaşılan koda izin verir.

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. Çoğu çerçevenin, yalnızca paylaşılan kodunuz varsa ve aksi takdirde ayrı projeler oluşturacak olmanız durumunda, farklı iş alanlarını tek bir projede karıştırmayı bekledikleri için teknik alana göre organize olduğunu düşünüyorum .

DÜZENLE:

Örneğin, bir şirketin deposunu işleyen bir web uygulaması olduğunu varsayalım. Genel formda bu birçok şirket için geçerli olabilir, ancak her birinin karşılanmayan ve satın almalarını yasaklayan bazı özellikleri olabilir. Örneğin, bunlardan biri forkliftlere tablet dağıttı ve diğerleri için özel bir görünüme ihtiyaç duyuyor öğeleri varsayılan iki yerine üç seviyeye düzenlemek için.

Elbette bu şirketlerin her biri için projeyi çatallayabilirsiniz. Ancak çerçeve / dil izin veriyorsa, genel projenin bitlerini ve parçalarını her müşterinin ihtiyaçlarına göre özelleştirmek ve bunları Business Domain düzenlerinde düzenlemek için alt sınıflandırma veya eklentiler vb. Kullanabilirsiniz.

Örneğin, genel proje JSON'a yalnızca Öğenin kendisini dışa aktarıyorsa, Domain1 denetleyiciyi alt sınıflandırabilir ve son teslim sorunlarını da dışa aktarabilir.

Daha sonra Domain1'in Domain2 için de geçerli bir bileşeni olduğunu fark ederseniz, jenerik sürümünü Paylaşılan'a çıkarabilirsiniz.

Dediğiniz gibi, teknik çerçeveye göre birçok çerçeve düzenliyor ve şimdilik kullandığım şey bu, çünkü FW seçimim bunu kolaylaştırıyor. Ama biraz (veya çok) dirsek yağı ile, ben de Business Domain düzenini desteklemek için dahil yollarını yeniden yazabilirsiniz düşünüyorum.

"Düzenli olarak daha fazla alan adı veya daha fazla teknik bölüm eklemek için daha olası olan şey nedir?" O zaman cevap ne olursa olsun, bunu en üst seviyeye koyun.

Çoğu durumda teknik mimariniz alan adınızdan daha hızlı katılaşacaktır. Bu, önce alana, ardından mimari bileşene göre organize etmeniz gerektiği anlamına gelir. Bunun nedeni, bir etki alanındaki bir şey değiştiğinde, o etki alanına birden çok teknik bileşen eklemeniz veya değiştirmeniz gerekebilir, ancak umarım bu yerelleştirilmiştir ve diğer etki alanlarına çok fazla dökülmez.

GUI çerçevenizi değiştirdiyseniz, bu, değişikliklerinizin tüm uygulamaya yayılacağı anlamına gelir, ancak daha sonra, GUI çerçevenizi nadiren değiştirirsiniz, ancak her zaman etki alanı mantığınızı değiştirirsiniz.

Aynı anda değişme olasılığı yüksekse işleri bir arada tutun.

Başka bir alternatif var ve bu, ek parçaları ayrı parçalara taşımaktır. CakePHP bunu örneğin yapıyor. İstediğiniz herhangi bir mantığa göre sıralayabileceğiniz yeniden kullanılabilir komple MVC parçaları oluşturmanıza izin verecektir.

Ana uygulamanız bunları kullanacak ve bağlantı verecektir.

Temelde sorunuz aynı zamanda uyum ve eşleştirme ile ilgilidir. Ayrı parçaların mümkün olduğunca bağımsız çalışmasını istiyorsunuz. Bu şekilde test edilebilir ve yeniden kullanılabilir kod elde edersiniz.

Bunu dikkate alarak: Etki alanına göre ayrılırsanız, uygulamanızın bazı bölümlerini nasıl yeniden kullanırsınız? Örneğin, bir web mağazası alın: / orders / view / 1 için bir istek gelir, bu nedenle nr sırasını göstermeniz gerekir. 1. / orders / controllers / order_controller adresine gidin. Etki alanını ürünler ve siparişlere göre ayırdıysanız, zaten diğer "etki alanının" bir kısmına ihtiyacınız olacaktır.

Orada şeyleri birbirine bağlamaya başlayabilirsiniz, ancak muhtemelen çoğu işte çok uyumludur. Teknik yaklaşımı benimserseniz. Örneğin, bir eklenti işleme siparişiniz olabilir. Merkezi nesnenizden Ürün nesnelerini koyuyorsunuz. Bu şekilde eklentiyi kolayca test edebilirsiniz, sadece bir isim ve fiyat ile bazı Ürün nesnesi oluşturun ve gönderin.

Eklenti tam olarak yapması gerekeni yapacak. Diğer "parçalara / alan adlarına / alanlarına" değil girdisine bağlı olacaktır.

Microsoft ASP.Net MVC 3 "Alanlar" kavramına sahiptir. MVC projenize "Alanlar" tanıttığınızda, onlar gibi ayırın:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

Bunu oldukça doğal buldum. Bir alan, bir projenin "büyük bir yığın" ıdır ve bağımsız bir birimde çalışmak çok mantıklıydı.

Eşleştirmek için ad alanlarını kullandık, FWIW.

300.000 kod satırından oluşan bir web mağazası ile kişisel deneyimimden, her zaman iş alanlarına göre organize etmeye giderdim. Bu şekilde, yalnızca bir işlevsel alanda çalışırken tüm ilgili sınıflara hızlı bir genel bakış elde edemezsiniz, Java'da paket görünürlüğünü de kullanabilirsiniz.

İlgilenenler için bazı ayrıntılar: Proje 5 yıl önce başlatıldığında, geliştiriciler aşağıdaki paket yapısını yarattı:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

Alışveriş sepeti, ürün arama vb. Gibi her mağaza işlevi, her biri kendi form sınıfına (MVC çerçevesi tarafından zorunlu kılınan yapı) sahip çeşitli eylemlerden oluşur. Sonuçta, her biri ilişkili form sınıfından tamamen ayrılan eylem paketinde 200'den fazla sınıf var. Daha da kötüsü, eylemler çok fazla mantık uygulamıyor, ancak başka bir pakette bulunan işleve özgü hizmetleri çağırıyor.

Ekibi, paketleri iş alanına göre düzenlemeye geçmemiz gerektiğine ikna ettim ve ikna ettim. Akıl yürütme basittir: Gerçekten tüm eylemlerin bir listesini görmek istiyorsanız, herhangi bir iyi IDE'nin tür hiyerarşi görünümünü açabilirsiniz. Ancak, IDE'nin yapamayacağı şey, bir sınıfın ait olduğu işletme etki alanını ortaya çıkarmaktır. Ayrıca, bu yaklaşım, yalnızca çeşitli işlevler için gerekli olan sınıfları herkese açık hale getirmenize izin verir, gerisini paketin görünürlüğünde tutar.

Birçok çerçevenin teknik alana göre ayrıldığını kabul ediyorum ve bu nedenle yeni bir çerçeve kullanırken sıklıkla bu şekilde başlıyorum. Ancak, sürekli olarak klasör organizasyonunun birincil düzeyi olarak iş etki alanını kullanmaya karar verdim.

Şahsen, Foo Denetleyicimi ve Foo Depomu veya her şeyi birlikte tutmanın, Denetleyici klasörü ile Depo klasörü arasında ileri geri gitmekten çok daha kolay olduğunu düşünüyorum, çünkü Foo'ya özellikler eklerken her ikisi de üzerinde çalışmam gerekiyor. Daha büyük projelerde, teknik klasörler arasındaki mesafe büyük olabileceğinden ve gelişirken fark edilir bir zaman kaybı olabileceğinden bu daha da önemlidir.