โครงสร้างแอ็พพลิเคชัน Java: แนวนอน vs แนวแยก

มีการถกเถียงกันเล็กน้อยเกี่ยวกับโครงสร้างโครงการเริ่มต้น (โดยใช้ Maven / Eclipse) สำหรับแอปพลิเคชัน Java ขนาดใหญ่

ตัวเลือกที่ 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)

ตัวเลือก 2:

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

ตัวเลือกที่ 2 จะทำให้โครงการ / โมดูล Maven ชัดเจนยิ่งขึ้นและหมายถึงคลาสที่จะสร้างฐานข้อมูลจะถูกกระจายไปในหลาย ๆ โครงการ ใครช่วยแนะนำข้อดีข้อเสียของแต่ละวิธีได้บ้าง?

ฉันขอแนะนำให้ทำไม่

การพยายามบังคับใช้เลเยอร์ทางเทคนิคพร้อมโครงสร้างแพ็กเกจนำไปสู่ความยุ่งเหยิงมากมายในแอปพลิเคชันของคุณ ไม่ต้องพูดถึงความจริงที่ว่าเราพยายามอย่างหนักเพื่อที่ซ่อนอยู่เบื้องหลังทุกอย่างที่มีอินเตอร์เฟซการบริการและสิ่งแรกที่เราทำ (ส่วนใหญ่เนื่องจากการบรรจุภัณฑ์) public classคือการทำทุกอย่าง สิ่งนี้จะเจ็บปวดเมื่อมีการแยกทางเทคนิคระหว่าง a x.y.z.serviceและx.y.z.repositoryแพ็คเกจตอนนี้ทุกอย่างสามารถเข้าถึงที่เก็บได้ บูมมีการห่อหุ้มของคุณภายในเลเยอร์บริการ

แต่คุณควรปฏิบัติตามแนวทางการทำงานและหัวหอมมากขึ้น ( สถาปัตยกรรมสะอาด , สถาปัตยกรรมหกเหลี่ยม ) สิ่งนี้สอดคล้องกับหลักการความรับผิดชอบเดี่ยว (เมื่อใช้กับแพ็คเกจ) และสอดคล้องกับหลักการบรรจุภัณฑ์

1. สิ่งที่เปลี่ยนแปลงด้วยกันจะถูกรวมเข้าด้วยกัน
2. สิ่งที่ใช้ร่วมกันจะถูกรวมเข้าด้วยกัน

Oliver Gierke ได้เขียนบทความที่ดีเกี่ยวกับส่วนประกอบบรรจุภัณฑ์เข้าด้วยกันใน Java Simon Brown ได้เขียนเรื่องทั่วไปมากขึ้นในเรื่อง

ฉันจะพยายามหาโครงสร้างแพ็คเกจหลักดังต่อไปนี้เพื่อเก็บแกนของแอปพลิเคชันของคุณ:

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

ตอนนี้ถ้าคุณมีเว็บอินเตอร์เฟสที่คุณเพิ่มตัวอย่างเช่นwebsubpackage สำหรับเว็บเซอร์วิซwsหรือrestแพ็คเกจเพื่อเก็บไว้เท่านั้น มันเชื่อมต่อกับแกนกลางเป็นหลัก

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

ตอนนี้คุณสามารถลองนำวัตถุจากภายในแกนของคุณกลับมาใช้เป็นเลเยอร์อื่นได้ แต่ IMHO จะเป็นการดีกว่าถ้าใช้โดเมนเฉพาะสำหรับเลเยอร์นั้น เช่นเดียวกับการแมป Object to SQL มี (ไม่บ่อย) ในสิ่งที่เราต้องการแสดงบนหน้าจอหรือใช้เป็น XML ในเว็บเซอร์วิซและวิธีการใช้ตรรกะทางธุรกิจ ทั้งนี้ขึ้นอยู่กับความซับซ้อนของธุรกิจและเว็บโดเมนที่คุณอาจคิดว่าพวกเขาเป็นโดเมนปัญหาแยกที่จะแก้ปัญหาซึ่งจะต้องมีการเชื่อมต่อโดยทั่วไป 2 ที่แตกต่างกันบริบทล้อมรอบ

หากต้องการใช้เครื่องหมายคำพูดจากทรัพยากร CQRS

ไม่สามารถสร้างโซลูชันที่ดีที่สุดสำหรับการค้นหาการรายงานและการประมวลผลธุรกรรมโดยใช้แบบจำลองเดียว

อย่าพยายามวางทุกสิ่งไว้ในรูปแบบเดียว (โดเมน) แยกความรับผิดชอบออกจากกัน คุณอาจจบลงด้วยคลาสที่เล็กกว่า แต่มีการแบ่งแยกที่ชัดเจนระหว่างเลเยอร์ของแอปพลิเคชันของคุณ

หมายเหตุสุดท้าย

โปรดจำไว้ว่าการสร้างสถาปัตยกรรมกำลังตัดสินใจเกี่ยวกับการแลกเปลี่ยนโซลูชันหนึ่งไปยังอีกโซลูชันหนึ่ง ขึ้นอยู่กับความซับซ้อนของโดเมนเป็นหลักและควรได้รับแรงผลักดันจากข้อกำหนดการทำงานของแอปพลิเคชันของคุณเป็นหลัก อย่างไรก็ตามมันได้รับอิทธิพลจากข้อ จำกัด ด้านประสิทธิภาพ, ความปลอดภัยและสิ่งแวดล้อม (ภาษาที่ใช้, แพลตฟอร์ม, ประสบการณ์) และสถาปัตยกรรมเช่นเดียวกับการเขียนโค้ดไม่เคยทำข้อกำหนดใหม่ให้เสร็จสมบูรณ์แต่ละข้อ (และอาจจะควร) นำไปสู่การออกแบบแอปพลิเคชันใหม่

คำปฏิเสธ

ใช่ฉันพยายามใส่ทุกอย่างไว้ในแบบจำลองเดียวและใช่ฉันยังพยายามใช้การแยกทางเทคนิคในแอปพลิเคชันของฉันด้วย อย่างไรก็ตามหลังจากสองสามปีของประสบการณ์ในการสร้าง layering แอพพลิเคชั่นที่ยุ่งเหยิง (ตอนแรกมันเป็นความคิดที่ดีจากนั้นแอพพลิเคชั่นก็เริ่มที่จะเติบโต ... ) ฉันคิดว่าต้องมีวิธีอื่น

การเชื่อมโยง

1. สถาปัตยกรรมสะอาดลุงบ็อบมาร์ติน
2. สถาปัตยกรรมหกเหลี่ยม (อาคาพอร์ตและอะแดปเตอร์), Alistair Cockburn
3. โอลิเวอร์ Gierke ของฉันไปทางไหน
4. หลักการของ OOD ลุง Bob Martin
5. ข้อผิดพลาดเมื่อใช้ DDD, Udi Dahan
6. บริบทที่ถูก จำกัด มาร์ตินฟาวเลอร์
7. สไตล์การเข้ารหัสที่เห็นได้ชัดในเชิงสถาปัตยกรรม, Simon Brown

หนังสือ

1. การพัฒนาซอฟต์แวร์เชิงวัตถุนำโดยการทดสอบ
2. Java Application Architecture: รูปแบบ Modularity พร้อมตัวอย่างโดยใช้ OSGi (Robert C. Martin Series)
3. การออกแบบที่ขับเคลื่อนด้วยโดเมน: การแก้ปัญหาความซับซ้อนในใจกลางของซอฟต์แวร์
4. สถาปัตยกรรมซอฟต์แวร์สำหรับนักพัฒนา
5. การใช้การออกแบบโดเมนขับเคลื่อน