Di mana Anda harus memvalidasi keadaan agregat “lainnya”?

Skenario:

Pelanggan memesan, kemudian, setelah menerima produk, memberikan umpan balik pada proses pemesanan.

Asumsikan akar agregat berikut:

• Pelanggan
• Memesan
• Umpan balik

Berikut adalah aturan bisnisnya:

1. Seorang pelanggan hanya dapat memberikan umpan balik atas pesanan mereka sendiri, bukan milik orang lain.

2. Pelanggan hanya dapat memberikan umpan balik jika pesanan telah dibayar.

   class Feedback {
       public function __construct($feedbackId,
                                   Customer $customer,
                                   Order $order,
                                   $content) {
           if ($customer->customerId() != $order->customerId()) {
               // Error
           }
           if (!$order->isPaid()) {
               // Error
           }
           $this->feedbackId = $feedbackId;
           $this->customerId = $customerId;
           $this->orderId = $orderId;
           $this->content = $content;
       }
   }
   

Sekarang, anggap bisnis menginginkan aturan baru:

3. Pelanggan hanya dapat memberikan umpan balik jika Supplierbarang pesanan masih beroperasi.

   class Feedback {
       public function __construct($feedbackId,
                                   Customer $customer,
                                   Order $order,
                                   Supplier $supplier,
                                   $content) {
           if ($customer->customerId() != $order->customerId()) {
               // Error
           }
           if (!$order->isPaid()) {
               // Error
           }
           // NEW RULE HERE
           if (!$supplier->isOperating()) {
               // Error
           }
           $this->feedbackId = $feedbackId;
           $this->customerId = $customerId;
           $this->orderId = $orderId;
           $this->content = $content;
       }
   }
   

Saya telah menempatkan implementasi dari dua aturan pertama dalam Feedback agregat itu sendiri. Saya merasa nyaman melakukan ini, terutama mengingat bahwa Feedbackagregat merujuk semua agregat lainnya berdasarkan identitas. Misalnya, sifat-sifat Feedbackkomponen menunjukkan bahwa ia mengetahui keberadaan agregat lain, jadi saya merasa nyaman mengetahui tentang status read only dari agregat ini juga.

Namun, berdasarkan sifat itu, yang Feedbackagregat tidak memiliki pengetahuan tentang keberadaan dari Supplieragregat, sehingga seharusnya ia memiliki pengetahuan tentang membaca satunya negara dari agregat ini?

Solusi alternatif untuk menerapkan aturan 3 adalah dengan memindahkan logika ini ke yang sesuai CommandHandler. Namun, ini terasa seperti memindahkan logika domain dari "pusat" arsitektur berbasis bawang saya.

Jika kebenaran transaksional membutuhkan satu agregat mengetahui tentang kondisi saat ini dari agregat lain, maka model Anda salah.

Dalam kebanyakan kasus, kebenaran transaksional tidak diperlukan . Bisnis cenderung memiliki toleransi terhadap data latensi dan basi. Ini terutama berlaku untuk inkonsistensi yang mudah dideteksi dan mudah diperbaiki.

Jadi perintah akan dijalankan oleh agregat yang mengubah status. Untuk melakukan pemeriksaan yang belum tentu benar, diperlukan belum tentu salinan terbaru dari keadaan agregat lainnya.

Untuk perintah pada agregat yang ada, pola yang biasa adalah meneruskan Repositori ke agregat, dan agregat akan meneruskan statusnya ke repositori, yang menyediakan kueri yang mengembalikan keadaan / proyeksi kekal dari agregat lainnya

class Feedback {
    void downvote(Repository<Supplier.State> query) {
        Supplier.State supplier = query.getById(this->supplierId);
        boolean isOperating = state.isOperating();
        ....
    }
}

Tetapi pola konstruksi aneh - ketika Anda membuat objek, penelepon sudah mengetahui keadaan internal, karena menyediakannya. Pola yang sama berfungsi, hanya terlihat tidak berguna

class Feedback {
    __construct(SupplierId supplierId, SupplierOperatingQuery query ...) {
        Supplier.State supplier = query.getById(this->supplierId);
        boolean isOperating = state.isOperating();
        ....
    }
}

Kami mengikuti aturan dengan menjaga semua logika domain di objek domain, tetapi kami tidak benar-benar melindungi invarian bisnis dengan cara yang bermanfaat dengan melakukannya (karena semua informasi yang sama tersedia untuk komponen aplikasi). Untuk pola pembuatan, akan sama baiknya untuk menulis

class Feedback {
    __construct(Supplier.State supplier, ...) {
        boolean isOperating = state.isOperating();
        ....
    }
}

Saya tahu ini adalah pertanyaan lama, tetapi saya ingin menunjukkan bahwa masalah ini secara langsung berasal dari premis yang salah. Artinya, akar agregat yang seharusnya kita asumsikan ada sama sekali tidak benar.

Hanya ada satu agregat root dalam sistem yang telah Anda jelaskan: Pelanggan. Baik Pesanan dan Umpan Balik, meskipun mereka mungkin merupakan agregat dalam hak mereka sendiri, bergantung pada Pelanggan untuk keberadaannya sehingga bukan merupakan akar agregat itu sendiri. Logika yang Anda berikan dalam konstruktor umpan balik Anda tampaknya menunjukkan bahwa Pesanan HARUS memiliki pelanggan dan Umpan Balik HARUS juga terkait dengan Pelanggan. Ini masuk akal. Bagaimana Pesanan atau Umpan Balik tidak dapat dikaitkan dengan Pelanggan? Selain itu, Pemasok tampaknya secara logis terkait dengan Pesanan (demikian juga dengan agregat ini).

Dengan pemikiran di atas, semua informasi yang Anda inginkan sudah tersedia di akar agregat Pelanggan dan menjadi jelas Anda menegakkan aturan Anda di tempat yang salah. Konstruktor adalah tempat yang mengerikan untuk menegakkan aturan bisnis dan harus dihindari dengan cara apa pun. Seharusnya terlihat seperti ini (Catatan: Saya tidak akan menyertakan konstruktor untuk Pelanggan dan Pesanan karena Pabrik mungkin harus digunakan. Juga tidak menampilkan semua metode antarmuka).

/*******************************\
   Interfaces, explained below 
\*******************************/

interface ICustomer
{
    public function getId() : int;
}

interface IUser extends ICustomer
{
    public function getUsername() : string;

    public function getPassword() : string;

    public function changeUsername( string $new ) : void;

    public function resetPassword( string $new ) : void;

}

interface IReviewer extends ICustomer
{
    public function provideFeedback( IOrder $order, string $content ) : void;
}

interface IBuyer extends ICustomer
{
    public function placeOrder( IOrder $order ) : void;
}

interface IOrder
{
    public function getCustomerId() : int;

    public function addFeedback( string $content ) : void;
}


interface IFeedback
{
    public function addContent( string $content ) : void;

    public function isValidContent( string $content ) : void;
}



/*******************************\
   Implentation
\*******************************/



class Customer implements IReviewer, IBuyer
{
    protected $id;

    protected $orders = [];

    public function provideFeedback( IOrder $order, string $content ) : void
    {
        if( $order->getCustomerId() !== $this->getId() )
            throw new \InvalidArgumentException('Customers can only provide feedback on their own orders');

        $order->addFeedback( $content );
    }
}


class Order implements IOrder
{
    protected $supplier;

    protected $feedbacks = [];

    public function addFeedback( string $content ) : void
    {
        if( false === $this->supplier->isOperating() )
            throw new \Exception('Feedback can only be added to orders if the supplier is still operating.');

        // could be any IFeedback
        $feedback = new Feedback( $this );

        $feedback->addContent( $content );

        $this->feedbacks[] = $feedback;
    }
}


class Feedback implements IFeedback
{
    protected $order;

    protected $content;

    public function __construct( IOrder $order )
    {    
         // we don't carry our business rules in constructors
         $this->order = $order;
    }

    public function addContent( string $content ) : void
    {
        if( false === $this->isValidContent($content) )
            throw new \Exception("Content contains offensive language.");

        $this->content = $content;
    }
}

Baik. Mari kita uraikan ini sedikit. Hal pertama yang Anda perhatikan adalah seberapa jauh deklaratif model ini. Semuanya adalah tindakan, menjadi jelas DI MANA aturan bisnis harus berlaku. Desain di atas tidak hanya "melakukan" hal yang benar, tetapi "mengatakan" hal yang benar.

Apa yang akan membuat orang menganggap aturan sedang dijalankan di baris berikut?

// this is a BAD place for rules to execute
$feedback = new Feedback( $id, $customerId, $order, $supplier, $content);

Kedua, Anda dapat melihat bahwa semua logika yang berkaitan dengan memvalidasi aturan bisnis dilakukan sedekat mungkin dengan model yang terkait. Dalam contoh Anda, konstruktor (metode tunggal) sedang melakukan beberapa validasi terhadap model yang berbeda. Itu merusak desain SOLID. Di mana kami akan menambahkan cek untuk memastikan bahwa konten Umpan Balik tidak mengandung kata-kata buruk? Periksa lagi di konstruktor? Bagaimana jika berbagai jenis Umpan Balik memerlukan pemeriksaan konten yang berbeda? Jelek.

Ketiga, melihat antarmuka, Anda dapat melihat ada tempat alami untuk memperluas / memodifikasi aturan melalui komposisi. Misalnya, berbagai jenis pesanan dapat memiliki aturan yang berbeda mengenai kapan umpan balik dapat diberikan. Pesanan juga dapat memberikan berbagai jenis umpan balik, yang pada gilirannya dapat memiliki aturan yang berbeda untuk validasi.

Anda juga dapat melihat banyak antarmuka ICustomer *. Ini digunakan untuk menyusun agregat Pelanggan yang kami butuhkan di sini (mungkin tidak hanya disebut Pelanggan). Alasannya sederhana. Sangat mungkin bahwa Pelanggan adalah akar agregat BESAR yang tersebar di seluruh domain / DB Anda. Dengan menggunakan antarmuka, kita dapat menguraikan satu agregat (yang kemungkinan terlalu besar untuk dimuat) menjadi beberapa agregat root yang hanya menyediakan tindakan tertentu (seperti memesan atau memberikan umpan balik). Anda dapat melihat agregat dalam implementasi saya dapat KEDUA memesan dan memberikan umpan balik, tetapi tidak dapat digunakan untuk mengatur ulang kata sandi atau mengubah nama pengguna.

Jadi jawaban untuk pertanyaan Anda adalah bahwa agregat harus memvalidasi diri mereka sendiri. Jika mereka tidak dapat Anda kemungkinan memiliki model yang kurang.