วิธีกำหนดขอบเขตของบริบทที่มีขอบเขตอย่างชัดเจน

หลังจากอ่านและค้นคว้า DDD มาหนึ่งเดือนฉันตัดสินใจเริ่มโครงการของตัวเองและสร้าง DDD ด้วยบริบทที่ล้อมรอบเหล่านี้>

• ลูกค้า
• ผลิตภัณฑ์
• สั่งซื้อ
• การเรียกเก็บเงิน

แต่ละบริบทที่ถูกล้อมรอบมี API ส่วนที่เหลือเป็นเลเยอร์การนำเสนอเลเยอร์โดเมนชั้นถาวร

จนถึงตอนนี้โค้ดก็ทำงานได้อย่างราบรื่น แต่มาจากโลกใบใหญ่ที่ฉันยังคงพยายามหาข้อมูลต่อไปนี้:

• เมื่อฉันต้องการสร้างลูกค้าใหม่ออกใบแจ้งหนี้ใหม่สร้างคำสั่งซื้อใหม่ที่ฉันต้องการตัวอย่างเช่นรายการการเข้าถึงของประเทศ ฉัน:

ก) สร้างรายชื่อประเทศในแต่ละปีก่อนคริสต์ศักราช

b) สร้างประเทศ BC -> API และใช้เพื่อรับรายชื่อประเทศที่มี

c) ใช้ API ของบุคคลที่สามและดึงข้อมูลผ่านเลเยอร์ anticoruption ในแต่ละ BC

• เมื่อรวมเข้ากับ API ของบุคคลที่สามโดยใช้เลเยอร์ต่อต้านการคอร์รัปชั่นหรือเลเยอร์อะแดปเตอร์จะต้องมีข้อมูลใดบ้างในโมเดลโดเมนของฉัน ตัวอย่างเช่นถ้าฉันต้องการรวม zendesk API กับ Client BC ฉันต้องการเพียง ticketID ในโดเมนของฉันหรือฉันต้องดึงข้อมูลทั้งหมดจาก Zendesk ที่ฉันต้องการเข้าถึงและใช้งานใน Client BC หรือไม่

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

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

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

ภายใน BCs เหล่านั้นคุณไม่ได้มุ่งเน้นไปที่คำนาม คุณมุ่งเน้นไปที่กรณีการใช้งานและสร้างรูปแบบของคำนามที่สามารถตอบสนองการใช้งานกรณี วิธีการใน "การรวมราก" ดำเนินการกรณีการใช้งานและทำการเปลี่ยนแปลงที่เหมาะสมกับรูปแบบที่เกี่ยวข้อง

... ทุกรุ่นผิด แต่บางรุ่นก็มีประโยชน์

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

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

จากคำถามของคุณฉันคิดว่าคุณเข้าใจบริบทที่ จำกัด คุณอาจต้องการอ่านบทที่ 14 ของหนังสือสีฟ้าอีกครั้ง

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

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

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

สิ่งที่ควรเกิดขึ้นในโดเมนของคุณเมื่อประเทศถูกครอบครองโดยต่างชาติ?

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

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

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

1. กำหนดความรับผิดชอบระดับสูงของระบบหรือความสามารถทางธุรกิจของคุณ วิธีที่ดีที่สุดที่จะทำฉันคิดว่าการคิดตามขั้นตอนที่องค์กรของคุณต้องทำเพื่อให้ได้มูลค่าทางธุรกิจ ขอบเขตเชิงตรรกะที่คุณพบคือธุรกิจบริการของคุณหรือหากคุณต้องการบริบทที่ จำกัด ขอบเขต
2. เจาะลึกในแต่ละบริการ
3. ระบุการสื่อสารระหว่างบริการของคุณพร้อมกับสองจุดแรก

ดังนั้นจุดเริ่มต้นคือการดำเนินธุรกิจของคุณ

คำแนะนำในการใช้งานจริง:

1. หากหนึ่งในบริบท / บริการ / ฯลฯ ของคุณต้องการข้อมูลของบริบทอื่น ๆ ขอบเขตของคุณอาจผิด
2. วิธีการสื่อสารบริบทที่เป็นที่ต้องการอย่างมากคืออิงเหตุการณ์ นี่คือกุญแจสู่ความยืดหยุ่นและความน่าเชื่อถือ หากคุณต้องการการสื่อสารแบบซิงโครนัสขอบเขตส่วนใหญ่ของคุณอาจไม่ถูกต้องอีกครั้ง นอกจากนั้นการสื่อสารแบบซิงโครนัสจะฆ่าระบบของคุณ
3. โดเมนของคุณจะมีความสอดคล้องกันมากกว่าที่คุณคิด เหมือนทุกคน อย่าพยายามทำให้ทุกอย่างสอดคล้องกัน 100% ไม่มีความหมายในทางปฏิบัติในที่
4. บริบทไม่จำเป็นต้องมีการจัดการ พวกเขาอยู่ในตัวเอง เหมือนมนุษย์

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