Etki alanı odaklı tasarım bir anti-SQL deseni midir?


43

Etki alanı odaklı tasarımda (DDD) dalış yapıyorum ve içinde daha derinlere indiğimde anlamadığım bazı şeyler var. Anladığım kadarıyla, ana nokta Etki Alanı Mantığını (İş Mantığı) Altyapıdan (DB, Dosya Sistemi vb.) Ayırmaktır.

Merak ettiğim şey, bir Malzeme Kaynağı Hesaplama Sorgusu gibi çok karmaşık sorularım olduğunda ne olur? Bu tür sorgularda, ağır küme işlemleriyle çalışıyorsunuz, SQL için tasarlanmıştı. Bu hesaplamaları Etki Alanı Katmanı içinde yapmak ve içinde çok sayıda kümeyle çalışmak, SQL teknolojisini çöpe atmak gibidir.

Altyapıda bu hesaplamaları yapmak da yapılamaz, çünkü DDD paterni Etki Alanı Katmanı'nı değiştirmeden ve MongoDB'nin gerçekleşemeyen SQL Server gibi aynı yeteneklere sahip olmadığını bilmeden altyapıdaki değişikliklere izin verir.

DDD paterninin bir çöküşü mü?


34
SQL, ilişkisel küme cebirini işlemek için tasarlanırken, iş mantığınızın yarısının, yeniden yapılandırılması zor ve hatta test etmesi zor olan bir avuç SQL işlevine gömüldüğünü fark ettiğinizde eğlenceli bir gün değildir. Böylece, bunu arkadaşlarıyla oynayabileceği etki alanı katmanına taşımak bana çekici geliyor. Bu, SQL teknolojisinin iyi bir parçası mı atıyor? Elbette, ancak SQL yalnızca SELECT / JOIN kullanıyorsanız yönetimi çok daha kolaydır.
Jared Goguen

30
@JaredGoguen ama bu bir SQL uzmanınız olmadığı için ve teknoloji yüzünden değil
Leonardo Mangano

2
@JimmyJames söylemeye çalıştığım şey, eğer DDD iyi uygulanmışsa, katmanları minimum çabayla değiştirmeyi sağlıyor, örneğin SQL Server'dan MongoDB'ye geçmek gibi. Ancak, SQL'de karmaşık sorgulamalar varsa, teknik farklılıkları nedeniyle MongoDB'ye geçemem mümkün olabilir. Sanırım bariz bir şey söyledim.
Leonardo Mangano

7
... is like throwing away the SQL technologySadece belirli bir teknoloji çünkü olabilir bunun en iyi seçim olduğu anlamına gelmez bir şey yap. Bu bir fıkra delilidir, ancak iş mantığını veritabanında depolayan ve neden olduğu uzun vadeli bakım baş ağrıları nedeniyle, bundan uzaklaşan çok fazla işletme ile tanıştım. Aşırı basitleştirme, ancak veritabanlarının veri depolaması ve programlama dillerinin veri dönüştürmesi içindir. Verilerimi doğrudan saklamak için uygulamamı kullanmak istediğimden daha fazla bir iş mantığı için DB kullanmak istemem.
Conor Mancone

8
SQL, DDD'nin harika bir örneği. İlgili verileri organize ederken, ilk önce insanlar bunu yapacak bir dil belirledi: SQL. Uygulama gerçekten önemli değil. Bir DB admin veritabanını sorgulamak için C / C ++ bilmeye ihtiyaç duymaz. Benzer şekilde, etkinlik planlaması görevi ile karşı karşıya kaldıklarında, birileri CRON sözdizimi (mhdmw) ile programlama problemlerinin% 99'una uyan basit bir etki alanı modeli ile karşılaştı. DDD'nin çekirdeği sınıflar ya da masalar vb.
Oluşturmak değildir

Yanıtlar:


38

Bu günlerde, okurları (sorguları) yazdıklarından (komutları) farklı bir şekilde ele aldığını görebilirsiniz. Karmaşık bir sorgusu olan bir sistemde, sorgunun kendisinin etki alanı modelini geçmesi olası değildir (bu, öncelikle yazma işleminin tutarlılığını korumaktan sorumludur ).

SQL olana SQL olarak vermemiz konusunda kesinlikle haklısın. Bu yüzden, okumaların etrafında optimize edilmiş bir veri modeli tasarlayacağız ve bu veri modelinin bir sorgusu genellikle etki alanı modelini içermeyen bir kod yoluna gidecektir (bazı girdi doğrulamaları hariç - sorgudaki parametrelerin sağlanması makul).


13
+1 İyi cevap, ama bu kavrama kendi ismini vermelisin, Komut Sorgu Ayrımı.
Mike,

6
@Mike Okuma ve yazma için tamamen farklı modellere sahip olmak, CQS yerine CQRS'ye benzer.
Andy

3
"Read model" etki alanı modeli değil mi? CQRS konusunda uzman değilim, ancak her zaman komut modelinin klasik alan modelinden oldukça farklı olduğunu, ancak okuma modelinden farklı olduğunu düşündüm. Yani belki bunun için bir örnek verebilirsin?
Doktor Brown

High Performance Mark'ın yazım kurallarına dikkat çektiğini anlamam çok uzun sürdü.
VoiceOfUnreason

@DocBrown - işte size açıklığa kavuşturma girişimim -> cascadefaliure.vocumsineratio.com/2019/04/…
VoiceOfUnreason

20

Anladığım kadarıyla, ana nokta Etki Alanı Mantığını (İş Mantığı) Altyapıdan (DB, Dosya Sistemi vb.) Ayırmaktır.

Yanlış anlaşılmanın temeli budur: DDD'nin amacı, "bu SQL sunucusunda, bu yüzden BL olmamalı" gibi sert bir çizgi boyunca işleri ayırmak değil, DDD'nin amacı alanları ayırmak ve arasında engeller oluşturmaktır. Bir etki alanının içindekilerin başka bir etki alanının içindekilerinden tamamen ayrı olmasına ve aralarındaki paylaşılan dışsallıkları tanımlamasına izin verenler.

BL / DL bariyeri olarak "SQL'de" olduğunu düşünmeyin - olan bu değil. Bunun yerine, bariyer olarak "bu iç alanın sonu" deyin.

Her etki alanı, diğer tüm etki alanlarıyla çalışmasına izin veren dışa dönük API'lere sahip olmalıdır : veri depolama katmanı durumunda, depoladığı veri nesneleri için okuma / yazma (CRUD) eylemleri olmalıdır. Bu, SQL'in kendisinin gerçekten bir engel olmadığı VIEWve PROCEDUREbileşenlerin olduğu anlamına gelir . : Tablonun doğrudan okumak asla harici tüketici olarak biz endişe etmemesi gerektiğini, bu DDD söyler uygulama detay.

Örneğinizi düşünün:

Merak ettiğim şey, bir Malzeme Kaynağı Hesaplama Sorgusu gibi çok karmaşık sorularım olduğunda ne olur? Bu tür sorgularda, ağır küme işlemleriyle çalışıyorsunuz, SQL için tasarlanmıştı.

Bu tam olarak SQL'de olması gereken şey ve bu bir DDD ihlali değil. O var biz DDD ne yaptı . SQL'deki bu hesaplama ile, BL / DL'nin bir parçası haline gelir . Eğer is kullanmak ne yapardı ayrı görünümü / saklı yordam / ne-sen-var ve olarak, iş mantığı veri katmanında ayrı tutulmasını o harici API olduğunu. Aslında, veri katmanınız başka bir DDD Etki Alanı Katmanı olmalı, veri katmanınızın diğer etki alanı katmanlarıyla çalışmak için kendi soyutlamalarını yapmalıdır .

Altyapıda bu hesaplamaları yapmak da yapılamaz, çünkü DDD paterni Etki Alanı Katmanı'nı değiştirmeden ve MongoDB'nin gerçekleşemeyen SQL Server gibi aynı yeteneklere sahip olmadığını bilmeden altyapıdaki değişikliklere izin verir.

Bu da bir yanlış anlama: Uygulama ayrıntılarının dahili olarak diğer etki alanı katmanlarını değiştirmeden değişebileceğini söylüyor . Altyapının tamamını değiştirebileceğiniz anlamına gelmez .

Yine unutmayın, DDD, iyi tanımlanmış harici API'ler içeren dahili kullanıcıları gizlemekle ilgilidir. Bu API'nin oturduğu yer tamamen farklı bir sorudur ve DDD bunu tanımlamaz. Basitçe bu API'nin var olduğunu ve asla değişmemesi gerektiğini tanımlar .

DDD, MSSQL'i geçici olarak MongoDB ile değiştirmenize izin verecek şekilde ayarlanmamış - bunlar iki farklı altyapı bileşeni.

Bunun yerine, DDD'nin tanımladığı şey için bir benzetme kullanalım: gazlı ve elektrikli arabalar. Her iki araç da itici güç oluşturmak için tamamen farklı iki yönteme sahip, ancak aynı API'leri var: açık / kapalı, bir gaz / fren ve aracı itecek tekerlekler. DDD aracımızdaki motoru (gaz veya elektrik) değiştirmemiz gerektiğini söylüyor. Arabayı bir motosikletle değiştirebileceğimizi söylemez ve bu da MSSQL → MongoDB'nin ne olduğudır.


1
Açıklama için teşekkürler. Benim için çok zor bir konu, herkesin farklı bir bakış açısı var. Kabul etmediğim tek şey, MSSQL (otomobil) ve MongoDB (motosiklet) arasındaki karşılaştırma, benim için doğru karşılaştırma bunların aynı otomobil için iki farklı motor olduğudur, ancak bu sadece bir fikir.
Leonardo Mangano

8
@LardoardoMangano Ah, ama değiller. MSSQL ilişkisel bir veritabanıdır, MongoDB bir doküman veritabanıdır. Evet, "veritabanı" her ikisini de açıklar, ancak bu konu mümkün olduğu kadarıyla ilgilidir. Okuma / yazma teknikleri tamamen farklıdır. MongoDB yerine, Postgre veya MySQL'i alternatif olarak kullanabilirsiniz ve bu geçerli bir karşılaştırma olacaktır.
410_Geçki

3
“Asla doğrudan masadan okumamalısın ...” Madness.
jpmc26

“Asla doğrudan masadan okumamalısınız ...” Bu, kurallara göre yapılandırılmış dersleri takip etmeye çalışmanın ilk acısı ile veritabanları ile etkileşime giren ve acı çeken bir on yıllık yazılımın ardından kendi başıma uygulamaya koyduğum bir kural. popüler tasarım desenleri.
Lucifer Sam

@LuciferSam Aye. Uygulama detayları ile etki alanı sınırları arasındaki ayrımı yönetmeyi çok daha kolaylaştırır. Etki alanındaki bir "nesne" 5 tabloyla temsil edilebilir, bu yüzden bu nesneyi kapsüllemek için bir Görünüm kullanıyoruz.
410_Geçen

18

Uygulamayı barındırmak için ödeme yapan kuruluşun, veritabanı katmanı lisanslarının çok pahalı olduğuna karar verdiği bir projede bulunduysanız, veritabanınızı / veri depolamanızı kolayca taşıyabileceğinizi takdir edersiniz. Her şey düşünüldü, bu olurken, sık sık olmaz .

Konuşmak için her iki dünyanın en iyisini elde edebilirsiniz. Veritabanındaki karmaşık fonksiyonları bir optimizasyon yapmayı düşünüyorsanız, alternatif bir hesaplama uygulaması için bir arayüz kullanabilirsiniz. Sorun, mantığı birden fazla yerde tutmanızdır.

Mimari düzenden sapma

Tamamen bir model uygulamak veya bir bölgeden sapmak konusunda kendinizi zor durumda bulursanız, o zaman bir karar vermeniz gerekir. Bir kalıp, projenizi düzenlemenize yardımcı olacak işleri yapmanın basit bir yoludur. Bu noktada değerlendirmek için zaman ayırın:

  • Bu doğru model mi? (çoğu zaman, ama bazen sadece kötü bir uyum)
  • Bu şekilde sapmalı mıyım?
  • Şimdiye kadar ne kadar saptım?

Bazı mimari kalıpların uygulamanızın% 80-90'ı için uygun olduğunu, ancak kalan bitler için pek uygun olmadığını göreceksiniz. Öngörülen düzenden ara sıra sapma, performans veya lojistik nedenlerden dolayı faydalıdır.

Ancak, kümülatif sapmalarınızın uygulama mimarinizin% 20'sinden daha iyi bir miktar oluşturduğunu tespit ederseniz, muhtemelen sadece kötü bir durumdur.

Mimarlığa devam etmeyi seçerseniz, kendinize bir iyilik yapın ve öngörülen şeylerden neden ve neden saptığınızı belgeleyin. Ekibinize yeni hevesli bir üye aldığınızda, bunları performans ölçümlerini ve gerekçelerini içeren belgelere yönlendirebilirsiniz. Bu, "sorunu" çözmek için tekrarlanan isteklerin olasılığını azaltacaktır. Bu dokümantasyon ayrıca, yaygın sapmaların fark edilmesine yardımcı olacaktır.


Cevaplarda "bu doğru kalıp budur" gibi kelime öbeklerini kullanmaktan kaçınırdım. İnsanların sorularını yazarken spesifik olmalarını sağlamak yeterince zor ve kendi girişinizle "bazen kötü bir uyum" diyerek bu, hayır, doğru model olmadığını gösterir.
Robert Harvey,

@RobertHarvey, kullanılan kalıbın uygulama için doğru olmadığı ve belirli kalite ölçümlerinin başarısız olmasına neden olduğu projelerde bulundum. Bu kesinlikle bir kural değil, ancak bu olduğunda mimariyi değiştirmek veya ayakkabı bağı kodunu uygulamaya koymak konusunda zor kararlar alıyorsunuz. Kötü uyumu ne kadar erken belirlerseniz, düzeltmesi o kadar kolay olur. Bu yüzden her zaman son durumları değerlendirirken bu düşünceyi dahil ediyorum. Son mermiyle birlikte, bazen sapmaların birikimini görene kadar ne kadar uygun olduğunu anlamıyorsunuz.
Berin Loritsch

6

SQL'in iyi olduğu set manipülasyon mantığı DDD ile sorunsuz şekilde entegre edilebilir.

Mesela bazı toplam değerleri, türe göre toplam ürün sayısını bilmem gerekiyor. Sql cinsinden çalıştırılması kolaydır, ancak her ürünü belleğe yükler ve hepsini eklersem yavaşlar.

Sadece yeni bir Domain nesnesi tanıtıyorum,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

ve havuzumdaki bir yöntem

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Tabii, belki de şimdi DB'ime belli yeteneklere sahip olduğuma güveniyorum. Fakat hala teknik olarak ayrılığa sahibim ve mantık basit olduğu sürece, bunun 'iş mantığı' olmadığını söyleyebilirim.


Şimdiye kadar hatırladım. Depoların da Queryparametre olarak alınması gerekiyordu . repository.find(query);. Aynısını okudum, ancak Specs. That opens a door to leave Query`li bir soyutlama ve QueryImplveya altyapı katmanına özgü sorgu uygulaması olarak okudum .
Laiv

5
aman tanrım, bazı insanların bunu yaptığını biliyorum ama bence korkunç. Bu tür şeyleri o yoldan bir adım olarak görebilirsiniz. Ancak dikkatli alınabileceğini düşünüyorum.
Ewan

I know some people do thatbazı insanlar çok önemlidir ve onun çerçevesidir. SpringFramework'da bunun çok var :-). Her neyse, @VoiceOfUnreason'ın önerdiği gibi, DDD'nin anahtarı, yazıların tutarlılığını korumaktır. Tasarımı yalnızca amaç sorgulama veya parametreleştirme olan etki alanı modelleriyle zorlamak konusunda emin değilim. Etki alanından veri yapılarıyla (pocos, pojos, dtos, row mappers, her neyse) yaklaşılabilir.
Laiv

Açıkçası, bu insanların akıl sağlığına kavuşmasına yardımcı olmak için bir tür engizisyona ihtiyacımız var. Ama silahlarıma yapıyorum. Veri katmanının kısmi maruz kalması, nesnel olarak "Etki Alanı Nesnesi" olan veya olmayan öznel olan daha iyi bir uygulama yapıldığında kabul edilebilirdir
Ewan

1
@LeonardoMangano, uygulamanıza ve uygulamanıza bağlıdır. Gerçekleşmesi gereken asıl şey, Etki Alanınızı uygulanabilir hale getirmek için yeniden yorumlayabilmenizdir.
Ewan

3

Bu ikilemi çözmenin olası yollarından biri, SQL'i bir montaj dili olarak düşünmektir: nadiren, eğer doğrudan kod içerisindeyseniz, ancak performans önemli olduğunda, C'niz tarafından üretilen kodu anlayabilmeniz gerekir. / C ++ / Golang / Rust derleyicisi ve hatta istediğiniz makine kodunu üretmek için üst seviyedeki kodunuzu değiştiremiyorsanız montajda küçük bir pasaj bile yazabilirsiniz.

Benzer şekilde, veritabanları ve SQL alanında, çeşitli SQL kütüphaneleri (bazıları ORM olan ), örneğin SQLAlchemy ve Python için Django ORM, .NET için LINQ , daha yüksek seviyeli soyutlamalar sağlar, ancak performans elde etmek için mümkün olan yerlerde üretilen SQL kodunu kullanırlar. Ayrıca, bazı daha optimal DB'ye özgü SQL kullanan bazı işlemler nedeniyle, muhtemelen farklı performansa sahip olan kullanılmış DB ile ilgili olarak bazı taşınabilirlik sağlarlar (örneğin Postgres ve MySQL).

Üstelik yüksek seviye dillerde olduğu gibi, SQL'in nasıl çalıştığını anlamak, sadece yukarıda belirtilen SQL kütüphaneleriyle yapılan sorguları yeniden düzenlemek, istenen etkinliği elde etmek için bile olsa önemlidir.

PS Bunu yorum yapmak yerine tercih ederim ama bunun için yeterli itibarım yok.


2

Her zamanki gibi, bu bir dizi faktöre bağlı olan şeylerden biri. SQL ile yapabileceğiniz birçok şey olduğu doğru. Ayrıca onu kullanmanın zorlukları ve ilişkisel veritabanlarının bazı pratik kısıtlamaları da vardır.

Jared Goguen yorumlarda belirtildiği gibi, SQL test etmek ve doğrulamak çok zor olabilir. Buna yol açan ana faktörler (genel olarak) bileşenlere ayrıştırılamamasıdır. Uygulamada, toto olarak karmaşık bir sorgu düşünülmelidir. Diğer bir karmaşık faktör, SQL'in davranış ve doğruluğu olmasının verilerinizin yapısına ve içeriğine büyük ölçüde bağımlı olmasıdır. Bu, olası tüm senaryoları test etmenin (veya onların ne olduğunu belirlemenin) çoğu zaman olanaksız veya imkansız olduğu anlamına gelir. SQL'in yeniden düzenlenmesi ve veritabanı yapısının değiştirilmesi de aynı şekilde problemlidir.

SQL'den uzaklaşmaya yol açan diğer büyük faktör ilişkisel veritabanları sadece dikey ölçeklendirme eğilimindedir. Örneğin, SQL Server'da çalıştırmak için SQL'de karmaşık hesaplamalar yaptığınızda, bunlar veritabanında yürütülecektir. Bu, tüm bu çalışmaların veritabanındaki kaynakları kullandığı anlamına gelir. SQL’de ne kadar çok işlem yaparsanız, veritabanınızın hem bellek hem de CPU açısından ihtiyaç duyduğu o kadar çok kaynak gerekir. Bunları diğer sistemlerde yapmak genellikle daha az etkilidir, ancak böyle bir çözüme ekleyebileceğiniz ek makine sayısının pratik bir sınırı yoktur. Bu yaklaşım, bir canavar veri tabanı sunucusu oluşturmaktan daha ucuz ve hataya dayanıklıdır.

Bu konular eldeki sorun için geçerli olabilir veya olmayabilir. Eğer probleminizi mevcut veritabanı kaynaklarıyla çözebiliyorsanız, belki de probleminiz için SQL sorun değil. Ancak, büyümeyi düşünmeniz gerekir. Bugün iyi olabilir ama yoldan birkaç yıl sonra, ek kaynak ekleme maliyeti bir sorun olabilir.


Bir canavar veritabanına alternatif değil, basitçe canavarca bir sayı ve yardımcı sistemlerin çeşitliliği değil mi? Tamamı çekirdek sistemi kapatırlarsa, yardımcı sistemler ne gibi esnekliğe sahiptir? Eğer gerekçelendirme basitçe çekirdek sistemin teknolojik kısıtlaması ise, bu çoğu iş sistemi için erken bir optimizasyon olacaktır. Genel olarak gerekli görüldüğü takdirde, SQL ayrıştırılmış bir şekilde yazılabilir.
Steve

@ Steve burada yanlış yaptığınız yerin, başkalarının 'kapattıkları' tek bir çekirdek sistemi olması gerektiğini varsaydığı kanısındayım.
JimmyJames

@Steve Bir örnek vermek gerekirse, bir sistemin tamamını bir veritabanını tek bir SQL olmayan veritabanıyla değiştirebilirsiniz (bunun her zaman doğru seçim olduğunu söylemiyorum, sadece yapılabileceği anlamına gelir.) Bu veritabanı daha sonra birçok alanda saklanabilir. sistemler, hatta coğrafi bölgeler. Böyle bir DB yardımcı değildir, SQL DB'nin toptan değişmesidir.
JimmyJames

@JimmyJames, kabul etti, ancak bir çekirdek sistem olmadığında, bağımlılıkları analiz ederek ve veri tutarlılığını koruyarak kendi sorunlarını yaratabilir. İlk başta monolitlerin nedeni budur - belli bir basitlik ve dolayısıyla belirli analiz ve bakım verimleri yaratırlar. Monolitik olmayan çözümler sadece başkaları için bazı problemleri veya maliyetleri değiştirir.
Steve

@jmoreno Bununla kaynaşmak için kaynakları bir yere atmak, iyi mühendislik dediğim şey değildir: "sitenin büyük veri hacmini idare etmek için ve işlem sayısına ayak uydurabilmek için 9.000 memcached örneği çalıştırıyor veritabanı hizmet vermeli. " Tasarımlarınızın maliyetini göz önünde bulunduruyor musunuz veya kişisel tercihlerinizi uygulanabilir hale getirmek için birinin para harcayacağını mı düşünüyorsunuz?
JimmyJames

2

DDD paterninin bir çöküşü mü?

İlk önce birkaç yanılgıyı çözeyim.

DDD bir kalıp değildir. Ve gerçekten kalıpları reçete etmez.

Eric Evan'ın DDD kitabının önsözü şöyle:

Önde gelen yazılım tasarımcıları, etki alanı modellemesini ve tasarımını en az 20 yıl boyunca kritik konular olarak kabul ettiler; Hiçbir zaman net bir şekilde formüle edilmemiş olmasına rağmen, nesne topluluğunda düşük akım olarak ortaya çıkan bir felsefe, alan odaklı tasarım dediğim bir felsefe ortaya çıkmıştır.

[...]

Başarılar için ortak olan bir özellik, tasarım yinelemeleriyle gelişen ve projenin dokusunun bir parçası olan zengin bir alan modelidir.

Bu kitap, tasarım kararları almak için bir çerçeve ve alan tasarımını tartışmak için teknik bir kelime sağlar. Kendi içgörü ve deneyimlerimle birlikte geniş çapta kabul gören en iyi uygulamaların bir sentezidir.

Bu nedenle, yazılım geliştirme ve etki alanı modellemeye, ayrıca bu etkinlikleri destekleyen bazı teknik kelimelere (çeşitli kavram ve kalıpları içeren bir kelime bilgisi) yaklaşmanın bir yolu. Aynı zamanda tamamen yeni bir şey değil.

Akılda tutulması gereken bir başka şey de, bir etki alanı modelinin, sisteminizde bulunabilecek OO uygulaması olmadığıdır - onu ifade etmenin ya da bir kısmını ifade etmenin sadece bir yolu. Etki alanı modeli, yazılımla çözmeye çalıştığınız sorun hakkında düşünme şeklinizdir. Bir şeyi nasıl anladığın ve algıladığın, onlar hakkında nasıl konuştuğun. Bu kavramsal . Ama belli belirsiz bir anlamda değil. Derin ve rafine, sıkı çalışma ve bilgi toplamanın bir sonucudur. Daha da rafine ve zaman içinde büyük olasılıkla gelişti ve uygulama ile ilgili düşünceleri içeriyor (bazıları modeli kısıtlayabilir). Bu edilmelidir tüm ekip üyeleri tarafından paylaşılan (ve ilgili alan uzmanları dahil) ve sistemi nasıl uyguladığınızı yönlendirmeli, böylece sistem onu ​​yakından yansıtmalıdır.

Bununla ilgili hiçbir şey, OO geliştiricileri genellikle modeli OO dillerinde ifade etmede daha iyi olsalar da ve birçok etki alanı kavramının ifadesi OOP tarafından daha iyi desteklense de, doğal olarak SQL karşıtı ya da karşıtı değildir. Ancak bazen modelin bölümleri farklı bir paradigmada ifade edilmelidir.

Merak ettiğim şey, çok karmaşık sorularım olduğunda ne olur [...]?

Genel olarak konuşursak, burada iki senaryo var.

İlk durumda, bir alanın bazı yönleri gerçekten karmaşık bir sorgu gerektirir ve belki de bu yön en iyi şekilde SQL / ilişkisel paradigmada ifade edilir - bu nedenle iş için uygun aracı kullanın. Etki alanınızdaki düşünceleri ve iletişim kurmada kullanılan dili düşünün. Etki alanı karmaşıksa, belki de bu, kendi sınırlanmış bağlamına sahip bir alt etki alanının bir parçasıdır.

Diğer senaryo, algılanan SQL'de bir şeyi ifade etme ihtiyacının kısıtlı düşüncenin bir sonucudur. Bir kişi veya ekip her zaman düşüncesine göre veritabanı yönelimli olmuşsa, eylemsizlik nedeniyle farklı şeylere yaklaşmanın farklı bir yolunu görmeleri onlar için zor olabilir. Bu, eski yöntem yeni ihtiyaçları karşılamadığında ve kutunun dışında düşünmeyi gerektiren bir problemdir. DDD, tasarıma bir yaklaşım olarak, kısmen etki alanı hakkındaki bilgileri toplayarak ve damıtıp bu kutudan çıkış yolunu bulma yollarıyla ilgilidir. Ancak herkes kitabın bu bölümünü görmezden geliyor gibi görünüyor ve listelenen bazı teknik kelime ve kalıplara odaklanıyor.


0

Hafıza pahalı olduğunda Sequel popüler oldu, çünkü ilişkisel veri modeli verilerinizi normalleştirme ve dosya sisteminde etkin bir şekilde saklama imkanı verdi.

Artık bellek nispeten ucuz, bu yüzden normalizasyonu atlayabilir ve kullandığımız formatta saklayabiliriz, hatta hız uğruna aynı veriyi çoğaltabiliriz.

Veritabanını , dosya sisteminde veri saklama sorumluluğu olan basit bir IO cihazı olarak düşünün - evet, bunu hayal etmenin zor olduğunu biliyorum, çünkü önemli iş mantığına sahip birçok SQL uygulaması sorgusu yazdık - ama sadece bu SQL Server'ı hayal etmeye çalışın sadece başka bir yazıcı.

PDF oluşturucuyu yazıcı sürücüsüne gömdünüz mü yoksa yazıcımızdan yazdırılan her müşteri siparişi için günlük sayfası basacak bir tetikleyici ekler misiniz?

Cevabın hayır olacağını kabul ediyorum, çünkü başvurumuzun belirli bir cihaz tipine bağlı olmasını istemiyoruz (bu tür bir fikrin verimliliği hakkında bile konuşmuyoruz)

70'li yıllarda 90'ların SQL veritabanı etkindi, değil mi? - Emin değilim, bazı senaryolarda eşzamansız veri sorgusu, SQL sorgusunda birden çok birleşmeden daha hızlı gerekli verileri döndürür.

SQL, karmaşık sorgular için tasarlanmadı, verileri verimli bir şekilde depolamak için tasarlandı ve daha sonra depolanan verileri sorgulamak için arabirim / dil sağladı.

Uygulamanızı, karmaşık sorgular içeren ilişkisel veri modeli etrafında oluşturmanın veritabanı motorunun kötüye kullanılması olduğunu söyleyebilirim. Tabii ki veritabanı motoru sağlayıcıları, işinizi ürünlerine sıkıca bağladığınızda çok mutlu olurlar - bu bağlılığı daha güçlü kılan daha fazla özellik sunmaktan çok mutlu olacaklardır.


1
Fakat SQL'in set hesaplamaları için diğer dillerden daha iyi olduğunu düşünüyorum. Benim açımdan. Örneğiniz ters, C # kullanarak milyonlarca satır ve birleştirme işleminin yapıldığı karmaşık işlemler için yanlış aracı kullanıyor, ancak hatalı olabilirim.
Leonardo Mangano

@LeonardoMangano, bazı örnekler: c # ile milyonlarca satırı küçültebilir ve paralel olarak hesaplayabilirim, zaman uyumsuz olarak veri alabilir ve veri döndüğünde "zaman" da hesaplamaları yapabilirim, c # ile düşük bellek kullanımı ile hesaplamaları yapabilirim. Satır Kodda karmaşık bir mantık olması, hesaplamaların nasıl yapılacağı konusunda size birçok seçenek sunar.
Fabio,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.