Domain Nedir ?

Bunu tanımlamak için önce bu bağlamda ve genel olarak gelişimde ne demek istediğimizi belirlemeliyiz . Bunun sözlük tanımı şudur: “Bir bilgi veya etkinlik alanı.” Bundan biraz aşağıya inecek olursak, yazılım mühendisliği alanında genellikle uygulamanın uygulanması amaçlanan konu alanını ifade eder. Başka bir deyişle, uygulama geliştirme sırasında , “uygulama mantığının etrafında döndüğü bilgi ve etkinlik alanı” dır. domain-driven-design

Yazılım geliştirme sırasında kullanılan bir diğer yaygın terimdir domain layerveya domain logicdaha iyi birçok geliştiriciler için bilinen ne varsa, business logic. business logicBir uygulama içi yüksek seviyeli kurallarına karşılık gelir business objects: (OOADoluşturmak ve model verileri değiştirmek için etkileşim kurar birbiriyle).

Domain Driven Design Nedir?

Başlangıçta ve onun 2004 kitabının, içinde programcı Eric Evans tarafından popüler hale gelen Domain-Driven Desing : Yazılımın Kalbinde Mücadele ve Karmaşıklık , üzerine genişlemesi ve uygulama bu yazılım geliştirme için geçerli olan, kavram. Yazılımın ilgili parçalarını sürekli gelişen bir modele bağlayarak karmaşık uygulamaların yönetilmesini kolaylaştırmayı amaçlamaktadır. Üç temel ilkeye odaklanır:

• Çekirdeğe odaklanın domainve domain logic.
• Karmaşık tasarımlar domain.
• domain expertsUygulama modelini iyileştirmek ve ortaya çıkan domainile ilgili sorunları çözmek için sürekli olarak işbirliği yapın .

Evans’ın Domain’e Dayalı Tasarımı , DDDuygulamaları açıklarken ve tartışırken faydalı olan birkaç genel terimi daha da tanımlar :

• Bağlam : Anlamını belirleyen bir kelimenin veya ifadenin göründüğü ayardır. Bir modelle ilgili ifadeler ancak bir bağlamda anlaşılabilir.
• Model : a’nın seçilen yönlerini tanımlayan domainve bununla ilgili sorunları çözmek için kullanılabilen bir soyutlama sistemi domain.
• Ubiquitous Language : domain modelTakımın tüm faaliyetlerini yazılımla birleştirmek için tüm ekip üyeleri tarafından kullanılan ve etrafında yapılandırılan bir dil .
• Sınırlı Bağlam : İçinde belirli bir modelin tanımlandığı ve uygulanabilir olduğu bir sınırın (tipik olarak bir alt sistem veya belirli bir ekibin çalışması).

Yapı Taşları

Domain-driven-designayrıca oluşturmak ve değiştirmek için birbiriyle bağlantılı olarak kullanılabilen bir dizi üst düzey kavramı tanımlar domain models:

• Entity : objectGeleneksel olanın aksine, kendi tutarlı sürekliliği objectsile tanımlanan attributes.
• Value Object : Belirgin bir kimliğe sahip olan ancak farklı bir kimliği olmayan immutable(değiştirilemez) .object attributes
• Domain Event : Sistem içindeki model etkinliğiyle ilgili ayrı bir olayı kaydetmek için kullanılan bir nesne. İken tüm sistem içindeki olaylar izleniyor olabilir, bir tek olay türleri için oluşturulan ilgili bakım.
• Aggregate: Bir küme entitiesve grubun etrafında belirlenen sınırlar ile. Her biri için tek tek veya tüm eylemleri kendi başına gerçekleştirmek yerine , öğeler topluluğuna tekil bir öğe atanır . Artık harici nesnelerin her bireye veya içindeki her bireye doğrudan erişimi yoktur , bunun yerine yalnızca tek bir öğeye erişimi vardır ve bunu, talimatları bir bütün olarak gruba iletmek için kullanır. Bu uygulamayı, serimizde ele aldığımız birçok gerçek kodlama uygulamasıyla ilişkilidir .
• Service: Esasen, a servicealanına doğal olarak uymayan bir işlem veya iş mantığı biçimidir objects. Başka bir deyişle, bazı işlevlerin olması gerekiyorsa, ancak bir entityveya ile ilişkilendirilemiyorsa , muhtemelen a'dır .
• Repositories: Ortak ile karıştırılmamalıdır version control repositories, DDDbir anlamı repository, bir olan serviceküresel bir arayüz kullanan tüm erişim sağlamak olduğunu entitiesve belirli bir mesafede olduğu koleksiyon. Yöntemler, içindeki nesnelerin oluşturulmasına, değiştirilmesine ve silinmesine izin verecek şekilde tanımlanmalıdır . Bununla birlikte, veri sorguları yapmak için bunu kullanarak , bu tür veri sorgulama yeteneklerini iş mantığı içinden kaldırmaktır .
• Factories : design patternskarmaşık nesneler oluşturmanın mantığını özetleyen ve müşterinin nesne manipülasyonunun iç işleyişi hakkında bilgi sahibi olmamasını sağlayan a'nın DDDkullanılmasını önermektedir .

Domain-driven-designayrıca continuous integration, tüm geliştirme ekibinden tek bir paylaşılan kod deposu kullanmasını ve günlük olarak (günde birkaç kez olmasa da) taahhütleri ona aktarmasını isteyen , her zamankinden daha popüler olan uygulamayı da yoğun bir şekilde vurgular . İşin sonunda, tüm kod tabanının bütünlüğünü kontrol eden, otomatik birim testleri, regresyon testleri ve benzerlerini çalıştıran, en son işlemlerde ortaya çıkabilecek olası sorunları hızla tespit eden otomatik bir süreç yürütülür.

Domain Driven Design Avantajları

• İletişimi Kolaylaştırır : Proje ubiquitousile ilgili ortak ve dil oluşturmaya erken bir vurgu yapan domain modelekipler için genellikle tüm geliştirme yaşam döngüsü boyunca iletişimi çok daha kolay bulacaktır. Genellikle, DDDuygulamanın yönleri tartışılırken daha az teknik jargon gerektirecektir, çünkü ubiquitous languageerken belirlenenler muhtemelen bu daha teknik yönlere atıfta bulunmak için daha basit terimler tanımlayacaktır.
• Esnekliği Artırır : DDDKavramları çok yoğun bir şekilde temel aldığı için , içindekileri hemen hemen her şey bir nesneye dayanacak ve bu nedenle oldukça modüler ve kapsüllü olacaktır. Bu çeşitli bileşenlerin ve hatta bir bütün olarak tüm sistemin düzenli ve sürekli olarak değiştirilmesine ve iyileştirilmesine izin verir.
• Domain İnterface : DDDKavramlar etrafında inşa etme pratiği ve proje içinde domain expertstavsiye DDDettiğinden domain, UI / UX'i vurgulayan uygulamaların aksine, genellikle eldeki için doğru ve temsili olan uygulamalar üretecektir. İlk ve en önemli. Açık bir denge gerekli olsa da, odaklanma, domainbir DDDyaklaşımın bununla ilişkili izleyici kitlesinde iyi yankı uyandıran bir ürün üretebileceği anlamına gelir.

Domain Driven Design Dezavantajları

• Sağlam Domain Uzmanlığı Gerektirir : Geliştirme üzerinde çalışan teknik açıdan en yetkin beyinler olsa bile domain expert, takımda uygulamanın uygulanması amaçlanan konu alanının tam olarak içini ve dışını bilen en az bir kişi yoksa, hepsi boşuna. . Bazı durumlarda, geliştirme yaşam döngüsü boyunca hareket edebilecek bir veya daha fazla dış ekip üyesinin entegrasyonunu gerektirebilir .
• Yinelemeli Uygulamaları Teşvik Eder : Birçoğu bunu bir avantaj olarak görse de, DDDuygulamaların gerektiğinde kendini ayarlayabilen şekillendirilebilir bir proje oluşturmak için sürekli yinelemeye ve sürekli entegrasyona güçlü bir şekilde dayandığı inkar edilemez . Bazı kuruluşlar, özellikle geçmiş deneyimleri büyük ölçüde waterfallmodel veya benzeri gibi daha az esnek geliştirme modellerine bağlıysa, bu uygulamalarla sorun yaşayabilir .

Umarım bu yazımda DDD’yi düzgün bir şekilde anlatabilmişimdir.