รูปแบบโดเมนที่หลากหลาย - พฤติกรรมนั้นเข้ากันได้อย่างไร

ในการอภิปรายเกี่ยวกับโมเดลโดเมน Rich and Anemic อินเทอร์เน็ตเต็มไปด้วยคำแนะนำทางปรัชญา แต่ย่อมาจากตัวอย่างที่เชื่อถือได้ วัตถุประสงค์ของคำถามนี้คือการหาแนวทางที่ชัดเจนและตัวอย่างที่เป็นรูปธรรมของโมเดลการออกแบบที่ขับเคลื่อนด้วยโดเมนที่เหมาะสม (นึกคิดใน C #.)

สำหรับตัวอย่างในโลกแห่งความจริงการใช้ DDD นี้ดูเหมือนจะผิด:

โดเมน WorkItem รุ่นด้านล่างไม่มีอะไรนอกจากถุงคุณสมบัติซึ่ง Entity Framework ใช้สำหรับฐานข้อมูลรหัสแรก ต่อฟาวเลอร์ก็เป็นโรคโลหิตจาง

เห็นได้ชัดว่าชั้น WorkItemService เป็นความเข้าใจผิดทั่วไปของบริการโดเมน มันมีพฤติกรรม / ตรรกะทางธุรกิจทั้งหมดสำหรับ WorkItem ต่อ Yemelyanov และคนอื่น ๆ ก็เป็นขั้นตอน (หน้า 6)

ดังนั้นถ้าด้านล่างผิดฉันจะทำให้ถูกต้องได้อย่างไร
พฤติกรรมเช่นAddStatusUpdateหรือCheckoutควรเป็นของคลาส WorkItem ที่ถูกต้องหรือไม่
แบบจำลอง WorkItem ควรพึ่งพาอะไร?

public class WorkItemService : IWorkItemService {
    private IUnitOfWorkFactory _unitOfWorkFactory;

    //using Unity for dependency injection
    public WorkItemService(IUnitOfWorkFactory unitOfWorkFactory) {
        _unitOfWorkFactory = unitOfWorkFactory;
    }

    public void AddStatusUpdate(int workItemId, int statusId) {

        using (var unitOfWork = _unitOfWorkFactory.GetUnitOfWork<IWorkItemUnitOfWork>()) {
            var workItemRepo = unitOfWork.WorkItemRepository;
            var workItemStatusRepo = unitOfWork.WorkItemStatusRepository;

            var workItem = workItemRepo.Read(wi => wi.Id == workItemId).FirstOrDefault();
            if (workItem == null)
                throw new ArgumentException(string.Format(@"The provided WorkItem Id '{0}' is not recognized", workItemId), "workItemId");

            var status = workItemStatusRepo.Read(s => s.Id == statusId).FirstOrDefault();
            if (status == null)
                throw new ArgumentException(string.Format(@"The provided Status Id '{0}' is not recognized", statusId), "statusId");

            workItem.StatusHistory.Add(status);

            workItemRepo.Update(workItem);
            unitOfWork.Save();
        }
    }
}

(ตัวอย่างนี้ทำให้ง่ายต่อการอ่านมากขึ้นรหัสยังคงเป็น clunky แน่นอนเพราะมันเป็นความพยายามที่สับสน แต่พฤติกรรมโดเมนคือ: อัปเดตสถานะโดยการเพิ่มสถานะใหม่ให้กับประวัติศาสตร์ที่เก็บถาวรในที่สุดฉันเห็นด้วยกับคำตอบอื่น ๆ นี้ สามารถจัดการได้โดย CRUD)

ปรับปรุง

@AlexeyZimarev ให้คำตอบที่ดีที่สุดวิดีโอที่สมบูรณ์แบบเกี่ยวกับเรื่องใน C # โดย Jimmy Bogard แต่เห็นได้ชัดว่ามันถูกย้ายไปเป็นความคิดเห็นด้านล่างเพราะมันไม่ได้ให้ข้อมูลมากไปกว่าลิงก์ ฉันมีร่างคร่าวๆของการสรุปวิดีโอในคำตอบของฉันด้านล่าง โปรดแสดงความคิดเห็นเกี่ยวกับคำตอบด้วยการแก้ไขใด ๆ วิดีโอยาวหนึ่งชั่วโมง แต่ดูคุ้มค่ามาก

อัพเดท - 2 ปีต่อมา

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

ฉันยังคงยินดีต้อนรับคำตอบใด ๆ สำหรับโพสต์นี้ (ใช้งานมาก) ที่ให้รหัสแนวทางปฏิบัติที่ดีที่สุดสำหรับรูปแบบโดเมนที่ถูกต้อง

คำตอบที่เป็นประโยชน์มากที่สุดได้รับจาก Alexey Zimarev และได้รับอย่างน้อย 7 upvotes ก่อนที่ผู้ดำเนินรายการย้ายมันไปเป็นความคิดเห็นด้านล่างคำถามเดิมของฉัน ....

คำตอบของเขา:

ฉันอยากจะแนะนำให้คุณดูเซสชั่น "งานหัตถกรรม Wicked Domain Models" ของ Jimmy Bogard ใน Vimeo เขาอธิบายว่าโดเมนใดควรเป็นโดเมนที่มีมากมายและวิธีการนำไปใช้ในชีวิตจริงโดยมีพฤติกรรมในหน่วยงานของคุณ ตัวอย่างเป็นจริงมากและทั้งหมดใน C #

http://vimeo.com/43598193

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

• "สำหรับแอปพลิเคชั่นส่วนใหญ่ ... เราไม่ทราบว่าพวกเขากำลังจะซับซ้อนเมื่อเราเริ่มต้นพวกเขากลายเป็นอย่างนั้น"
  • ความซับซ้อนจะเพิ่มขึ้นตามธรรมชาติเมื่อมีการเพิ่มรหัสและข้อกำหนด แอปพลิเคชันสามารถเริ่มต้นได้ง่ายมากเช่น CRUD แต่พฤติกรรม / กฎสามารถกลายเป็นสิ่งที่น่าสนใจ
  • "สิ่งที่ดีคือเราไม่ต้องเริ่มต้นที่ซับซ้อนเราสามารถเริ่มต้นด้วยโมเดลโดเมนโลหิตจางนั่นเป็นเพียงแค่ถุงสมบัติและด้วยเทคนิคการรีแฟคเตอร์มาตรฐานเราสามารถก้าวไปสู่โมเดลโดเมนที่แท้จริง"
• รูปแบบโดเมน = วัตถุธุรกิจ พฤติกรรมโดเมน = กฎเกณฑ์ทางธุรกิจ
• พฤติกรรมมักจะซ่อนอยู่ในแอปพลิเคชันซึ่งสามารถอยู่ใน PageLoad, Button1_Click หรือบ่อยครั้งในคลาสตัวช่วยเช่น 'FooManager' หรือ 'FooService'
• กฎทางธุรกิจที่แยกต่างหากจากวัตถุโดเมน "กำหนดให้เราต้องจำ" กฎเหล่านั้น
  • ในตัวอย่างส่วนตัวของฉันข้างต้นกฎข้อหนึ่งของธุรกิจคือ WorkItem.StatusHistory.Add () เราไม่เพียงแค่เปลี่ยนสถานะ แต่เรากำลังเก็บถาวรเพื่อการตรวจสอบ
• พฤติกรรมโดเมน "กำจัดข้อผิดพลาดในแอปพลิเคชันได้ง่ายกว่าการเขียนการทดสอบมากมาย" การทดสอบกำหนดให้คุณต้องรู้เพื่อเขียนการทดสอบเหล่านั้น พฤติกรรมโดเมนให้สิทธิ์แก่คุณในเส้นทางที่จะทดสอบ
• บริการโดเมนคือ "คลาสตัวช่วยในการประสานงานกิจกรรมระหว่างเอนทิตีโมเดลโดเมนที่ต่างกัน"
  • บริการโดเมน! = พฤติกรรมของโดเมน เอนทิตีมีพฤติกรรมบริการโดเมนเป็นเพียงตัวกลางระหว่างเอนทิตี
• วัตถุโดเมนไม่ควรมีโครงสร้างพื้นฐานที่ต้องการ (เช่น IOfferCalculatorService) บริการโครงสร้างพื้นฐานควรส่งผ่านไปยังรูปแบบโดเมนที่ใช้
• แบบจำลองโดเมนควรเสนอที่จะบอกคุณว่าพวกเขาสามารถทำอะไรได้บ้างและพวกเขาควรจะทำสิ่งเหล่านั้นได้
• คุณสมบัติของรุ่นโดเมนควรได้รับการปกป้องด้วย setters ส่วนตัวเพื่อให้เพียงรูปแบบสามารถตั้งค่าคุณสมบัติของตัวเองผ่านพฤติกรรมของตัวเอง มิฉะนั้นจะเป็น "promiscuous"
• วัตถุโมเดลโดเมน Anemic ที่เป็นเพียงคุณสมบัติถุงสำหรับ ORM เป็นเพียง "แผ่นไม้อัดบาง ๆ - เป็นรุ่นที่พิมพ์ลงบนฐานข้อมูล"
  • "อย่างไรก็ตามมันง่ายที่จะนำแถวฐานข้อมูลไปสู่วัตถุนั่นคือสิ่งที่เรามี"
  • 'แบบจำลองวัตถุที่คงทนถาวรส่วนใหญ่เป็นแบบนั้น สิ่งที่สร้างความแตกต่างของโมเดลโดเมนโลหิตจางเมื่อเทียบกับแอปพลิเคชันที่ไม่มีพฤติกรรมจริง ๆ คือถ้าวัตถุมีกฎเกณฑ์ทางธุรกิจ แต่ไม่พบกฎเหล่านั้นในรูปแบบโดเมน '
• "สำหรับแอปพลิเคชันจำนวนมากไม่จำเป็นต้องสร้างเลเยอร์ตรรกะแอปพลิเคชันธุรกิจจริง ๆ จริง ๆ เป็นเพียงบางสิ่งที่สามารถพูดคุยกับฐานข้อมูลและอาจเป็นวิธีง่ายๆในการนำเสนอข้อมูลที่อยู่ในนั้น"
  • ดังนั้นในคำอื่น ๆ ถ้าสิ่งที่คุณทำคือ CRUD โดยไม่มีวัตถุทางธุรกิจพิเศษหรือกฎพฤติกรรมคุณไม่จำเป็นต้อง DDD

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

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

ตัวอย่างเช่นถ้ามีความต้องการที่เฉพาะเจาะจงรายการงานสามารถมีสถานะที่เฉพาะเจาะจงหรือว่ามันจะมีเพียงสถานะ N แล้วว่าเป็นตรรกะโดเมนและควรเป็นส่วนหนึ่งของการอย่างใดอย่างหนึ่งWorkItemหรือStatusHistoryเป็นวิธีการที่

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

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

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

สมมติฐานของคุณที่รวมเอาตรรกะทางธุรกิจของคุณที่เกี่ยวข้องกับ WorkItem เข้ากับ "บริการไขมัน" เป็นรูปแบบการต่อต้านโดยธรรมชาติซึ่งฉันจะโต้แย้งไม่จำเป็น

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

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

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

ฉันรู้ว่าคำถามนี้ค่อนข้างเก่าดังนั้นคำตอบนี้สำหรับลูกหลาน ฉันต้องการที่จะตอบด้วยตัวอย่างที่เป็นรูปธรรมแทนที่จะเป็นหนึ่งในทฤษฎี

สรุปแค็ปซูล "การเปลี่ยนแปลงสถานะของรายการงาน" ในWorkItemคลาสดังนี้:

public SomeStatusUpdateType Status { get; private set; }

public void ChangeStatus(SomeStatusUpdateType status)
{
    // Maybe we designed this badly at first ;-)
    Status = status;       
}

ตอนนี้WorkItemชั้นเรียนของคุณมีหน้าที่รับผิดชอบในการรักษาตนเองในสถานะทางกฎหมาย อย่างไรก็ตามการใช้งานนั้นค่อนข้างอ่อน WorkItemเจ้าของผลิตภัณฑ์ที่ต้องการความเป็นมาของการปรับปรุงสถานะทั้งหมดที่ทำกับที่

เราเปลี่ยนเป็นอะไรแบบนี้:

private ICollection<SomeStatusUpdateType> StatusUpdates { get; private set; }
public SomeStatusUpdateType Status => StatusUpdates.OrderByDescending(s => s.CreatedOn).FirstOrDefault();

public void ChangeStatus(SomeStatusUpdateType status)
{
    // Better...
    StatusUpdates.Add(status);       
}

การใช้งานมีการเปลี่ยนแปลงอย่างมาก แต่ผู้เรียกใช้ChangeStatusเมธอดไม่ทราบรายละเอียดการใช้งานพื้นฐานและไม่มีเหตุผลที่จะเปลี่ยนแปลงตัวเอง

นี่คือตัวอย่างของเอนทิตีโมเดลโดเมนที่สมบูรณ์แบบ IMHO