Java uygulama yapısı: Yatay mı dikey mi bölündü

Büyük bir Java uygulaması için başlangıç ​​proje yapısı (Maven / Eclipse kullanarak) hakkında biraz tartışma yapmak.

Seçenek 1:

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

Seçenek 2:

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

Seçenek 2 açıkça çok daha fazla Maven projesi / modülü ile sonuçlanacaktır ve veritabanını oluşturacak sınıfların birden fazla proje arasında dağıtıldığı anlamına gelir. Herkes her yaklaşımın artılarını / eksilerini tavsiye edebilir mi?

İkisini de yapmamı öneririm.

Bir paket yapısıyla teknik katman oluşturmaya çalışmak, uygulamanızda çok fazla dolaşmaya yol açar. Bir servis arayüzünün arkasındaki her şeyi gizlemek için çok uğraştığımızdan bahsetmiyoruz ve yaptığımız ilk şey (çoğunlukla ambalajdan dolayı) her şeyi yapmaktır public class. Bu, a x.y.z.serviceve x.y.z.repositorypaket arasında teknik bir ayrım olduğunda ağrılı hale gelir , şimdi her şey depoya erişebilir. Boom orada servis katmanının içine giriyor.

Bunun yerine daha işlevsel ve soğan tabanlı bir yaklaşım izlemelisiniz ( temiz mimari , altıgen mimari ). Bu aynı zamanda Tek Sorumluluk İlkesine (bir pakete uygulandığında) ve ayrıca ambalajlama ilkelerine uygundur.

1. Birlikte değişen şeyler birlikte paketlenir
2. Birlikte kullanılan şeyler birlikte paketlenir

Oliver Gierke, Java'da birlikte paketleme bileşenlerine güzel bir yazı yazdı . Simon Brown bu konuda daha genel bir hikaye yazdı .

Uygulamanızın çekirdeğini tutmak için aşağıdaki gibi bir çekirdek paket yapısı için çaba göstereceğim:

x.y.z.area1
x.y.z.area2

Şimdi bir web arabiriminiz varsa, örneğin web hizmeti weba wsveya restpaketin yalnızca bunu tutması için bir alt paket eklersiniz . Temel olarak çekirdeğe bağlanır.

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

Şimdi nesneleri çekirdeğinizden diğer katmanlara tekrar kullanmayı düşünebilirsiniz, ancak IMHO o katman için belirli bir etki alanı kullanmak daha iyidir. Tıpkı Object to SQL mapping'de olduğu gibi, ekranda göstermek veya web hizmetinde XML olarak kullanmak istediğimiz şeyde ve iş mantığının nasıl uygulandığı konusunda (genellikle) bir uyumsuzluk vardır. İşletmenin ve web alan adlarının karmaşıklığına bağlı olarak, bunları bağlanması gereken ayrı sorun alanları olarak düşünebilirsiniz, temel olarak 2 farklı sınırlı bağlam .

Bir CQRS kaynağından alıntı kullanmak için

Tek bir model kullanarak işlemleri aramak, raporlamak ve işlemek için en uygun çözümü oluşturmak mümkün değildir.

Her şeyi tek bir (alan adı) modele sokmaya çalışmayın, sorumlulukları ayırın. Muhtemelen daha fazla (daha küçük) sınıfla sonuçlanırsınız ancak uygulamanızın katmanları arasında daha temiz bir ayrım vardır.

Son Not

Bir mimari yaratmanın bir çözümün diğerine değiş tokuşuna karar verdiğini unutmayın. Bu, alan adının karmaşıklığına bağlıdır ve esas olarak uygulamanızın fonksiyonel gereksinimleri tarafından yönlendirilmelidir. Ancak işlevsel olmayan (performans, güvenlik) ve çevresel kısıtlamalardan (kullanılacak dil, platform, deneyim) etkilenir. Ve mimari, kodlama gibi asla bitmez, her yeni gereksinim uygulamanın yeniden tasarımına yol açabilir (ve belki de?).

feragat

Evet, aynı zamanda her şeyi tek bir modele koymaya çalıştım ve evet uygulamalarımda da teknik bir ayırma kullanmaya çalıştım. Ancak dolaşık uygulama katmanı oluşturmada birkaç yıllık deneyimden sonra (ilk başta iyi bir fikir gibi görünüyor, sonra uygulama büyümeye başlıyor ...) Başka bir yol olması gerektiğini düşündüm.

Bağlantılar

1. Temiz Mimari, Bob Martin Amca
2. Altıgen Mimari (diğer bir deyişle Limanlar ve Adaptörler), Alistair Cockburn
3. Maalesef mimarim nereye gitti, Oliver Gierke
4. OOD İlkeleri, Bob Martin Amca
5. DDD, Udi Dahan uygulanırken yapılan hatalar
6. Sınırlı Bağlamlar, Martin Fowler
7. Mimari Olarak Belirgin Kodlama Stili, Simon Brown

Kitabın

1. Testler Rehberliğinde Büyüyen Nesneye Dayalı Yazılım
2. Java Uygulama Mimarisi: OSGi Kullanan Örneklerle Modülerlik Desenleri (Robert C. Martin Serisi)
3. Etki Alanında Tasarım: Yazılımın Kalbinde Karmaşıklıkla Mücadele
4. Geliştiriciler için Yazılım Mimarisi
5. Etki Alanına Dayalı Tasarımın Uygulanması