การออกแบบที่ขับเคลื่อนด้วยโดเมนพร้อม Entity Framework และรูปแบบพื้นที่เก็บข้อมูล [ปิด]

ฉันเคยจัดการกับแอปง่ายๆ ที่มี Service Layer ที่มีตรรกะทางธุรกิจทั้งหมด ใน การออกแบบที่ขับเคลื่อนด้วยโดเมน เป็นเรื่องปกติที่จะรักษาตรรกะทางธุรกิจไว้ในโมเดลที่สมบูรณ์

ดูบทแนะนำโดย Pluralsight ที่พวกเขาพูดถึง พื้นที่เก็บข้อมูล และสังเกตเห็นว่าโดยปกติแล้ว repo จะมีการดำเนินการ CRUD ขั้นพื้นฐาน (สร้าง อัปเดต ดึงข้อมูล และลบเอนทิตี) ไม่มีการอธิบายอะไรมากเกี่ยวกับ Entity Framework

Entity Framework 6 & Entity Framework Core ได้จัดเตรียม Repository/UoW ไว้เรียบร้อยแล้ว ฉันสงสัยว่าเราสามารถละเว้นการสร้าง Repository Layer ในกรณีนี้ได้หรือไม่

ฉันจะจินตนาการถึงแอปที่ไม่มีเลเยอร์ Repository แยกต่างหากได้อย่างไร...

ความเข้าใจของฉันคือ:

ตัวอย่างเช่น เรามีโมเดล Customer เป็นรากรวม (โมเดลโดเมนแบบสมบูรณ์) และแบบจำลองนั้นมีความสัมพันธ์แบบหนึ่งต่อกลุ่ม ICollection<Payment> Payments นอกจากนี้ ตาม DDD เราเก็บตรรกะของเราไว้ในโมเดล ดังนั้นเราจึงมีเมธอด MakePayment

รหัสจะเป็นดังนี้:

public class Customer
{
    public virtual ICollection<Payment> Payments { get; set; }

    // ... other properties/collections

    public void MakePayment(decimal amount)
    {
        this.Payments.Add(new Payment() { Amount = amount });
    }
}

ด้วย Entity Framework เราสามารถโหลดทั้งแผนผังอย่างกระตือรือร้น โดยผลลัพธ์ Customer มีการแมป Payments ทั้งหมดแล้ว

(เช่น เราจัดการกับแอป ASP.NET WebAPI)

ดังนั้น ในการชำระเงิน ฉันคิดว่าเราทำสิ่งต่อไปนี้:

1. ในตัวควบคุม/บริการของเรา เราได้ดึงข้อมูลลูกค้า (เช่น โดย id)

2. แล้วตามด้วยโค้ด customer.MakePayment(10);

3. หลังจากนั้นเราเรียกเมธอด dbContext.SaveChanges()

4. DbContext ติดตามการเปลี่ยนแปลงและจัดเก็บการชำระเงิน - Bingo!

ความเข้าใจของฉันถูกต้องหรือไม่

เกี่ยวกับชั้นบริการ:

จะเป็นไปได้ไหมที่จะมี Service Layer ที่มี DDD ในเว็บแอปดังกล่าว

ฉันยังคงคิดว่าการเก็บโค้ดไว้ในตัวควบคุมไม่ใช่สิ่งที่ถูกต้องเสมอไป (แม้จะใช้ DDD ก็ตาม) ตราบใดที่เช่น อาจจำเป็นต้องมีฟังก์ชันการทำงานบางส่วนในแอป WPF เพื่อให้เราสามารถใช้ Service Layer ได้

ดูเหมือนเป็นแนวทางที่เหมาะสมที่สุดใช่ไหม