Alan (DDD) tarafından yönetilen tasarım nedir?
Alanın (DDD) liderliğindeki tasarım 2004'ten beri dolaşımda olmuştur, ancak prosedür bu süre boyunca aşırı dağıtamamıştır. Ancak, terim birkaç yıldır ikinci bir bahar yaşadı. Bu nedenle, alan adının yönlendirdiği tasarımın ne olduğunu sormanın zamanı geldi.
Yazılımın geliştirilmesi kendi içinde bir son değildir. Bunun yerine, yazılım gerçek dünyadan teknik sorunları çözmek için geliştirilmiştir. Bu teknoloji gerektirir, ancak bu merkezde değil, sadece bir amaç için bir araçtır. Kraliyet Merkezi profesyonelliktir, bu yüzden başarının geliştirilmesi ve hedeflenen için iyi bir anlayış şarttır.
Teknik bir anlayış oluşturma gereksinimi, özellikle geliştiriciler için de geçerlidir. Nihayetinde, yazılım uzman uzmanların bilgisini yansıtmaz, ancak profesyonellik gelişiminde anlaşılanların sadece yorumudur ve gerçekte istenenlere az çok karşılık gelebilir.
İyi bir anlayış düzenli iletişim ve ortak bir dil yaratır, bu da özellikle disiplinler arası ekiplerde zorluktur: sonuçta, her disiplinin kendi teknik dili vardır, bu yüzden yanlış anlamalar kaçınılmazdır.
Bunun iyi bir örneği, günlük yaşamda “sürekli tekrarlayan” anlamına gelen, ancak yasal anlamda “ikinci bir kuralı” temsil eden “normal” kelimesidir. “Aralık” kelimesi, çevrimiçi pazarlamadan birisi için otomotiv sektöründeki birinden tamamen farklı bir anlama sahiptir. Bu yüzden burada yanlış anlamaları tanımak ve düzeltmek önemlidir.
Bu tam olarak alan adı (DDD) tarafından yönetilen tasarımın amacıdır. Terim, 2004 yılında “Tasarım-Birim Tasarım: Yazılımın Kalbindeki Karmaşıklığa Karşı Karşılama” adlı kitabının bir parçası olarak onu şekillendiren Eric Evans'tan kaynaklanmaktadır. Ana fikir, alan adını – yani profesyonelliği – yazılımın geliştirilmesinde ön plana çıkarmak ve ilgili disipline bakılmaksızın ilgili tüm konular için teknik dil hakkında ortak bir anlayışın olmasını sağlamaktır.
Evans, hakimiyeti ve her yerde bulunan dili çağıran ortak dilin modellenmesine yardımcı olabilecek bir dizi terim ve araç önerir. Nihayetinde, alan adının liderliğindeki tasarım, teknik eserler için doğru terimleri anlama, anlama ve aramakla ilgilidir.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Alan (DDD) tarafından yönetilen tasarım nedir?
Emretmek
Bu her yerde bulunan dilin bu amacına yaklaşmanın ilk yaklaşımı, kullanıcıların hedefleri olduğunu ve yazılım kullanmaları durumunda niyetleri takip etmektir. Kimse bir sayıyı değiştirmek için bir sayıyı değiştirmez, ancak ilişkili profesyonel etki için.
Bir sayıyı değiştirirken niyet, örneğin, yeni yasal gereksinimleri karşılamak için satış vergisi oranını ayarlamak olabilir. Teknik bir güncelleme, yol boyunca vergi uyarlamasının teknik yapısı olduğu ortaya çıkıyor. Bu anlambilim ve niyetler yazılımın modellenmesinde ve uygulanmasında gösterilmelidir.
Tabii ki, teknik niyet sonuçta teknik bir yapıya çevrilmelidir, çünkü teknik açıdan bahsedilen örnek aslında bir güncellemedir. DDD olmadan sıklıkla yapılan hata, bu çeviriyi olabildiğince geç yapmak değil, arı düzeyinde ve dolayısıyla kullanıcı arayüzünde gerçekleştirmektir, bu nedenle uygulamanın çoğunda teknik niyet kaybolur.
DDD, bir araç olarak adlandırılan “komutu” sağlar. Komut, teknik bir niyeti anlayan bir nesnedir. Bu nedenle tanımlayıcı bir isim taşır, örneğin “siparişi iptal eder”, aynı zamanda veri ve meta verilere sahiptir. Veriler teknik detaylar sağlarken (örneğin hangi sırayla mümkündür), meta veriler zaman damgası veya kimlik gibi teknik parametreler içerir.
Genel bir kural olarak, bir komutun adı zorunlu olan bir fiil ve bir isimden oluşur. Bu her zaman böyle olmamalıdır, ancak en azından iyi bir model olarak hizmet eder. Ayrıca, bir komutun komutun gönderildiği uygulama tarafından işlenmemesi gerekmediğini anlamak önemlidir: çeşitli teknik veya teknik nedenler olabileceği de reddedilebilir.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Tasarımdaki Komutlar Alan Adı (DDD)
Etki Alanı Etkinlikleri
Bir komutu bir eylem olarak anlarsanız, madalyanın bir dezavantajı olarak bir tepkinin beklendiği açıktır. DDD'de bunlar, gerçekleşen ve açıklanamayan bir gerçeği tanımlayan SO -Called “Etki Alanı Olaylarını” temsil eder. Örneğin, bir siparişin iptal edildiği gerçeği iptal edilemez, ancak iptalin etkisi bir karşı geçiş ile telafi edilebilir.
Aynı model, ilgisiz bir aktarımın açıklanamayacağı cari bir hesap bağlamında da bulunabilir, ancak banka tarafından borcun etkisi yine bir kredi ile telafi edilir.
Teknik açıdan bakıldığında, bir tahakküm olayı, bir ad, veri ve meta verilere sahip olduğu için bir komuta benzer. Bununla birlikte, komuttan farklı olarak, isim genellikle geçmişte bir isim ve bir fiil tarafından ifade edilir, örneğin zaten gerçekleştiğini ifade etmek için “düzenli sipariş”.
Bir komut ve tahakküm olayı, aralarında 1: 1 ilişki içinde olmamalıdır. Bir komutun farklı etki alanı olaylarını tetiklediği veya Alan adındaki A ve aynı olayın farklı komutlardan kaynaklandığı oldukça düşünülebilir. Başlangıçta teknik nedenlerle reddedilmedikçe, bir komutun her zaman en az bir tahakküm olayı ima etmesi önemlidir.
Bir tahakküm olayı sadece bir komuta tepki olarak değil, aynı zamanda potansiyel olarak ilgili diğer tarafları profesyonel olarak alakalı olaylar hakkında bilgilendirmek için de kullanılabilir. Bu bağlamda, uygulama genellikle olaylara dayalı mesajlar ve mimarilerle temasa geçer.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Domain (DDD) tarafından yönetilen tasarımdaki etki alanı olayları
Durum
Kontroller ve etki alanı olayları teknik veriler içerse de, bunlar bir komutun işlenmesi için ilgili tüm veriler değildir. Bazı durumlarda, komuttan bağımsız ve hangi sürenin komutun (kısa süre) hayatta kaldığı veriler gereklidir. Örneğin, bir siparişi iptal ettiğinizde, bilgiler sipariş orijinal olarak terk edildiğinde hizmet edebilir, çünkü iptal sadece 14 gün içinde mümkün olmalıdır.
Bu bilgi bir uygulamanın “durumunu”, yani tüm teknik nesnelerin mevcut durumunu temsil eder. Komutlar devleti değiştirir, hakimiyet olayları modifikasyonu hakkında bilgi sağlar. Bununla birlikte, yurtiçi olaylar da ortaya çıkabilir, ancak devlet değiştirilmemiştir, çünkü yaratma teknik olarak bir örnekle de ilgili olabilir, örneğin, müşteri hizmetlerinin neye tepki vermesi gerektiğini iptal etme talebini reddetmek.
Devlet için önemli bir gereklilik, her zaman tutarlı, güvenilir ve doğru olmasıdır. Bu nedenle komut atomik yapmalıdır, tutarlılık bakımı, birbirini engellememeli ve kalıcı değişiklikler içermelidir. Ardından, ilişkisel veritabanlarından bildikleri gibi klasik asit kriterlerini takip edin. Komutların, tahakkuk eden olayların etkileşiminde bu kriterleri garanti etmek uygulamaya bağlıdır.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Alanın liderliğindeki tasarımda durum (DDD)
Toplular
Bu tam olarak DDD olarak adlandırılan “agregaları” karşılamanın amacıdır. Sonunda, bir agrega, teknisyenlerdeki ve mantıksal olarak bir araya gelen ve mantıksal olarak birbirine ait olan, ilgili komutlar ve etki alanı olayları ile kapsülün bir kabuktan başka bir şey değildir.
Bir komutun her zaman tam olarak bir toplamı ifade ettiğini bilmek önemlidir. Dolayısıyla, her bir birim içindeki asidik kriterlere uymaktan sorumlu olduğundan, işlem açısından mantıklı olmayacak çapraz komut yoktur. Bu nedenle DDD, bazen agregaların “işlemsel bir kenarı” temsil ettiğini de söyler.
Ortaya çıkan soru, agregaları ideal olarak nasıl kesmeniz gerektiğidir. Büyük agregalar teknik çatışmaları önler, ancak gerektiğinde komutların serileştirilmesi gerektiğinden kullanım kullanımında tarafa zarar verir. Küçük agregalar bu aksesuarı teşvik eder, ancak hızla profesyonel çatışmalara yol açar. Bu nedenle gerçek ortada: agregalar gerekenden en büyüğü olmalı, ancak mümkün olduğunca küçük olmalıdır.
Opere verimli tasarım toplama bu konuda DDD'nin en büyük zorluklarından biridir, ancak aynı zamanda en büyük fırsatlardan biridir: potansiyel teknik ve kurumsal riskleri, olasılıklarını ve tehlikelerini tam olarak budur. Teknik yollarla düşünülebilen herhangi bir mesleki problemi çözmek önemli değildir, daha ziyade birbirlerine yönelik çaba ve riskleri değerlendirmek önemlidir.
Kesinlikle, acil bir durumda elle daha iyi çözülebilen teknik bir bakış açısıyla çözülmemiş kalabilecek sorunlar vardır. Bunların hangi sorunların olduğunu ve hangi etkilerinin, agregaların tasarımındaki en önemli faktörlerden biri olduğunu öğrenin.
Önerilen editoryal içerik
Rızanızla, burada harici bir YouTube videosu (Google Ireland Limited) burada davet edilir.
YouTube videosu her zaman yüklenir
YouTube videosu artık yüklüyor
Alanın liderliğindeki tasarımdaki agregalar (DDD)
Çözüm
DDD doğal olarak çok daha fazlasını içermesine rağmen, ilk adımda komutlar, alan adı, durum ve toplu olaylara DDD ile başlamak için teknik bir bakış açısıyla gerekli değildir. Bununla birlikte, atlama noktası bu araçları ders kitabına göre uygulamak değil, bunları bir amaç için bir araç olarak anlamaktır. Bu nedenle ana amaç, disiplinlerarası bir ekipte ortak ve profesyonel bir dil bularak DDD'nin gerçek anlamından kaynaklanmalıdır.
Bu zorluğun teknoloji ile neredeyse hiçbir ilgisi olmaması, ana faktörlerden biri olmalı, çünkü DDD neredeyse 20 yıldır ana akıma girmedi. Ciddi DDD uygulamak, teknik konfor alanını geliştirici olarak bırakmak ve yeni, tamamen bilinmeyen topraklarda özenli olmak anlamına gelir. Bu cesaret, merak, ilgi ve empati gerektirir.
Bununla birlikte, bu özellikleri taşıyanlar, DDD'yi başarılı bir şekilde kullanabilmek için en önemli araçları elinde tutarlar. Öte yandan, DDD'yi Eric Evans'ın kitap modellerine düşüren herkes resmi olarak DDD'yi takip ediyor, ancak asıl hedef çok uzak. Sonunda, dört çetenin nesnesine yönelik ünlü tasarım modellerinde olduğu gibi, DDD örnek uygulama ile ilgili değil, tabandaki temel fikir – ve bu çok sık biliniyor.
()