ฉันควรจัดระเบียบโฟลเดอร์ตามโดเมนธุรกิจหรือโดเมนทางเทคนิคหรือไม่

ตัวอย่างเช่นถ้าฉันใช้สถาปัตยกรรมที่คล้ายกับ MVC ฉันควรใช้โครงสร้างโฟลเดอร์ใด:

domain1/
    controller
    model
    view
domain2/
    controller
    model
    view

หรือ:

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

ฉันจงใจละทิ้งนามสกุลไฟล์เพื่อรักษาคำถามผู้ไม่เชื่อเรื่องภาษานี้

โดยส่วนตัวฉันต้องการแยกจากโดเมนธุรกิจ (ความรู้สึก gut) แต่ฉันเห็นว่ากรอบการทำงานส่วนใหญ่ / หลายแยกจากโดเมนทางเทคนิค ทำไมฉันถึงต้องเลือกอันใดอันหนึ่ง?

ฉันคิดว่าสิ่งนี้ขึ้นอยู่กับโครงการเฉพาะ

ตัวอย่างเช่นหากโดเมนธุรกิจที่แตกต่างกันมีความเป็นอิสระต่อกันฉันจะจัดระเบียบตามโดเมนธุรกิจ

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

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

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 ฉันคิดว่ากรอบงานส่วนใหญ่จัดระเบียบตามโดเมนทางเทคนิคเพียงเพราะพวกเขามีแนวโน้มที่จะคาดหวังว่าคุณจะรวมโดเมนธุรกิจที่แตกต่างกันเป็นโครงการเดียวก็ต่อเมื่อคุณมีรหัสที่ใช้ร่วมกันและจะสร้างโครงการแยกต่างหาก

แก้ไข:

ตัวอย่างเช่นสมมติว่ามีเว็บแอปที่จัดการคลังสินค้าของ บริษัท ในรูปแบบทั่วไปสิ่งนี้อาจนำไปใช้กับหลาย ๆ บริษัท แต่แต่ละ บริษัท อาจมีรายละเอียดบางอย่างที่ไม่ได้พบและห้ามไม่ให้ซื้อตัวอย่างเช่นหนึ่งในนั้นได้ปรับใช้แท็บเล็ตกับรถยกและต้องการมุมมองพิเศษสำหรับพวกเขา เพื่อจัดระเบียบรายการเป็นสามระดับแทนที่จะเป็นค่าเริ่มต้นของสอง

แน่นอนคุณสามารถแยกโครงการสำหรับแต่ละ บริษัท เหล่านี้ แต่ถ้าเฟรมเวิร์ก / ภาษาอนุญาตคุณสามารถใช้คลาสย่อยหรือปลั๊กอิน ฯลฯ เพื่อกำหนดบิตและชิ้นส่วนของโครงการทั่วไปตามความต้องการของลูกค้าทุกคนและจัดระเบียบพวกเขาในเลย์เอาต์ Business Domain

เช่นถ้าโครงการทั่วไปส่งออกไปยัง JSON เฉพาะรายการเท่านั้น Domain1 สามารถแบ่งคลาสตัวควบคุมและทำให้การส่งออกเป็นปัญหาการส่งล่าสุด

และหากคุณพบภายหลังว่า Domain1 มีส่วนประกอบที่ใช้ได้กับ Domain2 ด้วยคุณสามารถแยกรุ่นทั่วไปไปยัง Shared ได้

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

ฉันคิดว่าการรู้แจ้งจะถามว่า "ฉันมีแนวโน้มที่จะเพิ่มอะไรเป็นประจำโดเมนเพิ่มเติมหรือแผนกเทคนิคเพิ่มเติม" ถ้าอย่างนั้นคำตอบก็คือวางที่ระดับสูงสุด

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

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

เก็บสิ่งต่าง ๆ เข้าด้วยกันหากพวกมันมีแนวโน้มที่จะเปลี่ยนแปลงในเวลาเดียวกัน

มีทางเลือกอื่นและนั่นคือการย้ายส่วนแยกต่างหากในปลั๊กอิน CakePHP ทำเช่นนั้น มันจะช่วยให้คุณสร้างชิ้นส่วน MVC ที่สมบูรณ์ซึ่งสามารถนำกลับมาใช้ใหม่ได้ซึ่งคุณสามารถเรียงลำดับตามตรรกะที่คุณต้องการ

แอปพลิเคชันหลักของคุณจะใช้และลิงก์ไปยังพวกเขา

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

โดยคำนึงถึงสิ่งนั้น: หากคุณแยกตามโดเมนคุณจะนำชิ้นส่วนของแอปพลิเคชันของคุณกลับมาใช้อย่างไร ตัวอย่างเช่นใช้เว็บช็อป: คำขอมาใน / orders / view / 1 ดังนั้นคุณต้องแสดงคำสั่งซื้อ nr 1. ไปที่ / orders / controllers / order_controller หากคุณแยกโดเมนตามผลิตภัณฑ์และคำสั่งซื้อคุณจะต้องมีส่วนของ "โดเมน" อื่น ๆ อยู่แล้ว

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

ปลั๊กอินจะทำสิ่งที่จำเป็นต้องทำ มันจะขึ้นอยู่กับการป้อนข้อมูลของมันและไม่ได้อยู่ใน "ชิ้นส่วน / โดเมน / พื้นที่" อื่น ๆ

Microsoft ASP.Net MVC 3 มีแนวคิด "พื้นที่" เมื่อคุณแนะนำ "พื้นที่" ในโครงการ MVC ของคุณพวกเขาจะแยกย่อยเช่น:

area1/
   models
   views
   controllers
area2/
   models
   views
   controllers

ฉันพบว่ามันค่อนข้างเป็นธรรมชาติ พื้นที่คือ "ก้อนใหญ่" ของโครงการและการทำงานในหน่วยที่มีอยู่ในตัวเองนั้นสมเหตุสมผลมาก

เราใช้เนมสเปซเพื่อจับคู่ FWIW

จากประสบการณ์ส่วนตัวของฉันกับร้านค้าบนเว็บที่ประกอบด้วยโค้ด 300,000 บรรทัดฉันมักจะไปจัดระเบียบโดเมนธุรกิจ ด้วยวิธีนี้คุณไม่เพียง แต่จะได้รับภาพรวมอย่างรวดเร็วของคลาสที่เกี่ยวข้องทั้งหมดเมื่อคุณทำงานในพื้นที่การทำงานหนึ่งใน Java คุณยังสามารถใช้ประโยชน์จากการมองเห็นแพคเกจ

รายละเอียดบางอย่างสำหรับผู้ที่สนใจ: เมื่อโครงการเริ่ม 5 ปีที่ผ่านมานักพัฒนาสร้างโครงสร้างแพ็คเกจต่อไปนี้:

com
  example
    web
      struts
        action
        form
      shared
      functionality1
      functionality2

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

ฉันแนะนำและสร้างความมั่นใจให้กับทีมว่าเราควรเปลี่ยนไปใช้การจัดระเบียบแพ็คเกจตามโดเมนธุรกิจ การให้เหตุผลนั้นง่าย: ถ้าคุณต้องการเห็นรายการการกระทำทั้งหมดคุณสามารถเปิดมุมมองลำดับชั้นของประเภทของ IDE ที่เหมาะสมได้ อย่างไรก็ตามสิ่งที่ IDE ไม่สามารถทำได้คืออนุมานว่าโดเมนธุรกิจเป็นคลาส นอกจากนี้วิธีการดังกล่าวยังช่วยให้คุณสามารถเปิดเผยเฉพาะคลาสที่เป็นที่ต้องการของฟังก์ชันการใช้งานต่างๆ

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

โดยส่วนตัวแล้วฉันคิดว่ามันง่ายกว่ามากที่จะเก็บ Foo Controller และ Foo Repository ของคุณไว้ด้วยกันหรืออะไรก็ตามที่นอกเหนือจากการกลับไปกลับมาระหว่างโฟลเดอร์ของ Controller กับโฟลเดอร์ Repository บ่อยครั้งที่ฉันต้องทำงานทั้งสองเมื่อเพิ่มฟีเจอร์รอบ ๆ Foo ในโครงการขนาดใหญ่สิ่งนี้มีความสำคัญมากกว่าเนื่องจากระยะห่างระหว่างโฟลเดอร์ทางเทคนิคนั้นยอดเยี่ยมและเสียเวลาอย่างเห็นได้ชัดขณะพัฒนา