บริบทและโดเมนที่ถูก จำกัด DDD?

ฉันทำงานในแอปพลิเคชั่นที่ค่อนข้างซับซ้อนด้วยตารางฐานข้อมูล 10 รายการ (Aggregates, Entities / Object Objects) และการใช้ DDD ณ จุดนี้ดูเหมือนว่าโดยทั่วไปแล้ว DDD-Lite หมายถึงมี Application / Domain Services, Domain Model (เอนทิตี, Object Value) และ Repositories

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

ขณะนี้ฉันพยายามจัดรูปแบบโดเมนโดยความสัมพันธ์แบบรวมและใช้เนมสเปซเพื่อสาธิต

ฉันไม่เห็นประโยชน์ / ข้อผิดพลาดที่เกี่ยวข้องกับการแยกโครงการ Domain Model ออกเป็นบริบทที่ถูกผูกมัด (ยัง) บางทีมันอาจจะชัดเจนในภายหลัง แต่ฉันต้องการความคิดเห็นเกี่ยวกับชีวิตจริงในบริบทที่ถูกผูกไว้ (และอาจเป็นโดเมนย่อยเป็นต้นหากพวกเขาเชื่อมโยงเข้ากับมัน)

พิจารณา บริษัท ที่มีแผนกต่างกัน:

• การพัฒนาซอฟต์แวร์
• ทรัพยากรบุคคล
• การบัญชี

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

• ผู้พัฒนา
• ลูกจ้าง
• ผู้รับเงิน

ความพยายามในการสร้างอินสแตนซ์ผู้ใช้ในแต่ละบริบทนั้นแตกต่างกันมาก บางทีมันอาจเป็นแบบนี้:

• พนักงานใหม่ (ssn, ชื่อ, joindate, dateofbirth, เพศ)
• นักพัฒนาใหม่ (พนักงานเวิร์กสเตชันข้อมูลประจำตัว)
• ผู้รับเงินใหม่ (พนักงาน, บทบาท)

ยกตัวอย่างยกตัวอย่างยากที่จะแสดงให้เห็นอย่างแม่นยำโดยไม่มีรูปแบบโดเมนที่เหมาะสมในการอ้างอิง

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

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

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

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

• แคตตาล็อกสินค้าที่คุณเก็บรายละเอียดผลิตภัณฑ์และคุณสมบัติทั้งหมดของคุณ
• สินค้าคงคลังที่คุณมีระดับสต็อกสินค้า

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

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

Update: มีการถ่ายทอดทักษะที่ดีใน SkillsMatter จาก Eric Evans เขาให้ความคล้ายคลึงของเรื่องเก่าเมื่อชายตาบอดหลายคนอธิบายช้างจากมุมมองของพวกเขา เนื่องจากมนุษย์แต่ละคนสามารถสัมผัสได้เพียงส่วนหนึ่งของช้างพวกเขาจึงอธิบายว่ามันเป็น "ต้นไม้", "ผนัง", "งู", "เชือก" และผู้ชายแต่ละคนนั้นถูกต้องภายในบริบทของพวกเขา บริบทที่มีขอบเขตคือภาษาที่มีชีวิตทุกวัน นอกบริบทคำเหล่านี้อาจมีความหมายแตกต่างกันโดยสิ้นเชิง แต่ในบริบทนี้ภาษาเดียวกันในหลายโดเมน Greg Young แนะนำอย่างยิ่งให้เริ่มอ่านหนังสือสีฟ้าจากบทที่ 11 เนื่องจากมีการอธิบายแนวคิดพื้นฐานที่สำคัญที่สุด การมุ่งเน้นไปที่รูปแบบทางยุทธวิธีในตอนต้นของหนังสือทำให้วิธี "DDD-light" นี้เป็นเรื่องธรรมดามาก