Bagaimana menerapkan beberapa konsep DDD ke kode aktual? Pertanyaan khusus di dalam


9

Saya telah mempelajari DDD dan saat ini saya berjuang untuk menemukan cara untuk menerapkan konsep dalam kode aktual. Saya memiliki sekitar 10 tahun pengalaman dengan N-tier, jadi sangat mungkin bahwa alasan saya berjuang adalah bahwa model mental saya terlalu digabungkan dengan desain itu.

Saya telah membuat Aplikasi Web Asp.NET dan saya mulai dengan domain sederhana: aplikasi pemantauan web. Persyaratan:

  • Pengguna harus dapat mendaftarkan Aplikasi Web baru untuk dipantau. Aplikasi web memiliki nama yang ramah dan menunjuk ke URL;
  • Aplikasi web secara berkala akan memilih status (online / offline);
  • Aplikasi web akan melakukan polling secara berkala untuk versi saat ini (aplikasi web diharapkan memiliki "/version.html", yang merupakan file yang menyatakan versi sistemnya dalam markup tertentu).

Keraguan saya terutama menyangkut pembagian tanggung jawab, menemukan tempat yang tepat untuk setiap hal (validasi, aturan bisnis, dll). Di bawah, saya telah menulis beberapa kode dan menambahkan komentar dengan pertanyaan dan pertimbangan.

Mohon kritik dan saran . Terima kasih sebelumnya!


MODEL DOMAIN

Dimodelkan untuk merangkum semua aturan bisnis.

// Encapsulates logic for creating and validating Url's.
// Based on "Unbreakable Domain Models", YouTube talk from Mathias Verraes
// See https://youtu.be/ZJ63ltuwMaE
public class Url: ValueObject
{
    private System.Uri _uri;

    public string Url => _uri.ToString();

    public Url(string url)
    {
        _uri = new Uri(url, UriKind.Absolute); // Fails for a malformed URL.
    }
}

// Base class for all Aggregates (root or not).
public abstract class Aggregate
{
    public Guid Id { get; protected set; } = Guid.NewGuid();
    public DateTime CreatedAt { get; protected set; } = DateTime.UtcNow;
}

public class WebApp: Aggregate
{
    public string Name { get; private set; }
    public Url Url { get; private set; }
    public string Version { get; private set; }
    public DateTime? VersionLatestCheck { get; private set; }
    public bool IsAlive { get; private set; }
    public DateTime? IsAliveLatestCheck { get; private set; }

    public WebApp(Guid id, string name, Url url)
    {
        if (/* some business validation fails */)
            throw new InvalidWebAppException(); // Custom exception.

        Id = id;
        Name = name;
        Url = url;
    }

    public void UpdateVersion()
    {
        // Delegates the plumbing of HTTP requests and markup-parsing to infrastructure.
        var versionChecker = Container.Get<IVersionChecker>();
        var version = versionChecker.GetCurrentVersion(this.Url);

        if (version != this.Version)
        {
            var evt = new WebAppVersionUpdated(
                this.Id, 
                this.Name, 
                this.Version /* old version */, 
                version /* new version */);
            this.Version = version;
            this.VersionLatestCheck = DateTime.UtcNow;

            // Now this eems very, very wrong!
            var repository = Container.Get<IWebAppRepository>();
            var updateResult = repository.Update(this);
            if (!updateResult.OK) throw new Exception(updateResult.Errors.ToString());

            _eventDispatcher.Publish(evt);
        }

        /*
         * I feel that the aggregate should be responsible for checking and updating its
         * version, but it seems very wrong to access a Global Container and create the
         * necessary instances this way. Dependency injection should occur via the
         * constructor, and making the aggregate depend on infrastructure also seems wrong.
         * 
         * But if I move such methods to WebAppService, I'm making the aggregate
         * anaemic; It will become just a simple bag of getters and setters.
         *
         * Please advise.
         */
    }

    public void UpdateIsAlive()
    {
        // Code very similar to UpdateVersion().
    }
}

Dan kelas DomainService untuk menangani Create and Deletes, yang saya yakin bukan urusan Agregat itu sendiri.

public class WebAppService
{
    private readonly IWebAppRepository _repository;
    private readonly IUnitOfWork _unitOfWork;
    private readonly IEventDispatcher _eventDispatcher;

    public WebAppService(
        IWebAppRepository repository, 
        IUnitOfWork unitOfWork, 
        IEventDispatcher eventDispatcher
    ) {
        _repository = repository;
        _unitOfWork = unitOfWork;
        _eventDispatcher = eventDispatcher;
    }

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
    {
        var webApp = new WebApp(newWebApp);

        var addResult = _repository.Add(webApp);
        if (!addResult.OK) return addResult.Errors;

        var commitResult = _unitOfWork.Commit();
        if (!commitResult.OK) return commitResult.Errors;

        _eventDispatcher.Publish(new WebAppRegistered(webApp.Id, webApp.Name, webApp.Url);
        return OperationResult.Success;
    }

    public OperationResult RemoveWebApp(Guid webAppId)
    {
        var removeResult = _repository.Remove(webAppId);
        if (!removeResult) return removeResult.Errors;

        _eventDispatcher.Publish(new WebAppRemoved(webAppId);
        return OperationResult.Success;
    }
}

LAPISAN APLIKASI

Kelas di bawah ini menyediakan antarmuka untuk domain WebMonitoring ke dunia luar (antarmuka web, sisanya api, dll). Ini hanya sebuah shell pada saat ini, mengarahkan kembali panggilan ke layanan yang sesuai, tetapi akan tumbuh di masa depan untuk mengatur lebih banyak logika (selalu dilakukan melalui model domain).

public class WebMonitoringAppService
{
    private readonly IWebAppQueries _webAppQueries;
    private readonly WebAppService _webAppService;

    /*
     * I'm not exactly reaching for CQRS here, but I like the idea of having a
     * separate class for handling queries right from the beginning, since it will
     * help me fine-tune them as needed, and always keep a clean separation between
     * crud-like queries (needed for domain business rules) and the ones for serving
     * the outside-world.
     */

    public WebMonitoringAppService(
        IWebAppQueries webAppQueries, 
        WebAppService webAppService
    ) {
        _webAppQueries = webAppQueries;
        _webAppService = webAppService;
    }

    public WebAppDetailsDto GetDetails(Guid webAppId)
    {
        return _webAppQueries.GetDetails(webAppId);
    }

    public List<WebAppDetailsDto> ListWebApps()
    {
        return _webAppQueries.ListWebApps(webAppId);
    }

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
    {
        return _webAppService.RegisterWebApp(newWebApp);
    }

    public OperationResult RemoveWebApp(Guid webAppId)
    {
        return _webAppService.RemoveWebApp(newWebApp);
    }
}

Menutup Masalah

Setelah mengumpulkan jawaban di sini dan di pertanyaan lain ini , yang saya buka untuk alasan yang berbeda tetapi akhirnya sampai pada titik yang sama dengan yang ini, saya datang dengan solusi yang lebih bersih dan lebih baik ini:

Proposisi solusi dalam Github Gist


Saya sudah banyak membaca, tetapi saya tidak menemukan contoh-contoh praktis seperti itu, kecuali yang menerapkan CQRS dan pola dan praktik ortogonal lainnya, tetapi saya sedang mencari hal sederhana ini sekarang.
Levidad

1
Pertanyaan ini mungkin lebih cocok untuk codereview.stackexchange.com
VoiceOfUnreason

2
Saya sendiri menyukai Anda dengan banyak waktu yang dihabiskan dengan aplikasi n-tier. Saya tahu tentang DDD hanya dari buku, forum, dll, jadi saya hanya akan mengirim komentar. Ada dua jenis validasi: validasi input dan validasi aturan bisnis. Validasi input masuk dalam lapisan Aplikasi dan validasi Domain berlaku di Lapisan Domain. WebApp lebih mirip Entitas dan bukan agreagate dan WebAppService lebih mirip layanan aplikasi daripada DomainService. Juga agregat Anda merujuk Container yang merupakan masalah infrastruktur. Ini juga terlihat seperti pencari lokasi layanan.
Adrian Iftode

1
Ya, karena itu tidak memodelkan suatu hubungan. Agregat memodelkan hubungan antara objek domain. WebApp hanya memiliki data mentah dan beberapa perilaku dan mungkin berurusan misalnya dengan invarian berikut: tidak ok untuk memperbarui versi seperti gila yaitu melangkah ke versi 3 ketika versi saat ini adalah 1.
Adrian Iftode

1
Selama ValueObject memiliki metode yang mengimplementasikan kesetaraan antara instance, saya pikir tidak masalah. Dalam skenario Anda, Anda bisa membuat objek nilai versi. Periksa versi semantik, Anda akan mendapatkan banyak ide tentang bagaimana Anda bisa memodelkan objek nilai ini, termasuk invarian dan perilaku. WebApp tidak boleh berbicara dengan repositori, sebenarnya saya percaya aman untuk tidak memiliki referensi dari proyek Anda yang berisi hal-hal domain ke hal lain yang berkaitan dengan infrastruktur (repositori, unit kerja) baik secara langsung atau tidak langsung (melalui antarmuka).
Adrian Iftode

Jawaban:


1

Panjang garis saran pada WebAppagregat Anda , saya sepenuhnya setuju bahwa menarik repositorybukan pendekatan yang tepat di sini. Dalam pengalaman saya, Agregat akan membuat 'keputusan' apakah suatu tindakan baik-baik saja atau tidak berdasarkan keadaannya sendiri. Jadi bukan pada negara itu mungkin menarik dari layanan lain. Jika Anda memerlukan cek semacam itu, saya biasanya akan memindahkannya ke layanan yang memanggil agregat (dalam contoh Anda WebAppService).

Selain itu, Anda dapat menggunakan use case yang beberapa aplikasi ingin secara bersamaan memanggil agregat Anda. Jika ini akan terjadi, sementara Anda melakukan panggilan keluar seperti ini yang mungkin memakan waktu lama, Anda dengan demikian memblokir agregat Anda untuk penggunaan lainnya. Ini pada akhirnya akan memperlambat penanganan agregat, sesuatu yang saya pikir juga tidak diinginkan.

Jadi, meskipun tampaknya agregat Anda menjadi sangat tipis jika Anda memindahkan sedikit validasi, saya pikir lebih baik untuk memindahkannya ke WebAppService.

Saya juga menyarankan untuk memindahkan penerbitan WebAppRegisteredacara ke agregat Anda. Agregat adalah orang yang sedang dibuat, jadi jika proses penciptaannya berhasil, masuk akal untuk membiarkannya menerbitkan pengetahuan itu kepada dunia.

Semoga ini bisa membantu Anda keluar dari @Levidad!


Halo Steven, terima kasih atas masukan Anda. Saya telah membuka pertanyaan lain di sini bahwa ultimatelly sampai ke titik yang sama dari pertanyaan ini, dan akhirnya saya menemukan upaya Solusi Bersih untuk masalah ini. Bisakah Anda melihat dan membagikan pemikiran Anda? Saya pikir ini sesuai dengan saran Anda di atas.
Levidad

Tentu Levidad, saya akan lihat!
Steven

1
Saya baru saja memeriksa kedua balasan, dari 'Voice of Unreason' dan 'Erik Eidt'. Keduanya sejalan dengan apa yang akan saya komentari pada pertanyaan yang Anda punya di sana, jadi saya tidak bisa benar-benar menambah nilai di sana. Dan, untuk menjawab pertanyaan Anda: Cara Anda WebAppmengatur AR di 'Solusi Bersih' yang Anda bagikan memang sejalan dengan apa yang saya pandang sebagai pendekatan yang baik untuk Agregat. Semoga ini bisa membantu Anda keluar Levidad!
Steven
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.