"Bu makale dizisinde, Domain Driven Desgin (etki alnına dayalı tasarım)'ın ne olduğunu ve projenize - veya bir kısmının - projelerinize nasıl uygulanacağını öğreneceksiniz." diyor Petter Holmström. Ben de elimden geldiğince bu yazı dizisini Türkçe'ye çevirmeye çalışacağım. Umarım İngilizce okumada zorluk çeken arkadaşlar için yararlı olur.
Yazı Dizisinin Orjinali
Örnek DDD projesi
Serinin diğer yazıları :
1 - Strategic Domain Driven Design (Stratejik DDD)
2 - Tactical Domain Driven Design (Taktiksel DDD)
Her iki bağlam da aynı sanal makinenin içinde çalıştığından, her iki bağlamla doğrudan etkileşime giren yalnızca bir adaptöre ihtiyacımız var. Adaptör, aşağı akış bağlamının bağlantı noktası arabirimini uygular ve yukarı akış bağlamının bağlantı noktasını çağırır. Herhangi bir bağlam eşlemesi adaptörün içinde gerçekleşir.
Yazı Dizisinin Orjinali
Örnek DDD projesi
Serinin diğer yazıları :
1 - Strategic Domain Driven Design (Stratejik DDD)
2 - Tactical Domain Driven Design (Taktiksel DDD)
Önceki iki makalede, stratejik ve taktiksel alan odaklı tasarım hakkında bilgi sahibi olduk. Şimdi bir domain modelini çalışan yazılıma nasıl dönüştüreceğinizi, daha spesifik olarak bunun altıgen mimariyi kullanarak nasıl yapılacağını öğrenmenin zamanı geldi.
Önceki iki makale, kod örnekleri Java ile yazılmış olsa da oldukça geneldi. Bu makaledeki pek çok teori diğer ortamlarda ve dillerde de uygulanabilir olsa da, bunu açıkça Java ve Vaadin ile yazdım.
Yine içerik, Eric Evans'ın Domain-Driven Design: Tackling Complexity in the Heart of Software and Implementing Domain-Driven Design by Vaughn Vernon kitaplarına dayanıyor ve ikisini de okumanızı şiddetle tavsiye ediyorum. Ancak önceki makalelerde de kendi düşüncelerimi, fikirlerimi ve deneyimlerimi sunmuş olsam da, bu daha da güçlü bir şekilde düşündüklerim ve inandıklarımla renkleniyor. Bununla birlikte, beni DDD ile başlatan şey Evans ve Vernon'un kitaplarıydı ve burada yazdıklarımın kitaplarda bulacaklarınızdan çok da uzak olmadığını düşünmek istiyorum.
Bu, bu makalenin ikinci versiyonu. İlkinde, port kavramını yanlış anlamıştım. Bu, minnettar olduğum bir okuyucu tarafından yapılan bir yorumda belirtildi. Şimdi bu hatayı düzelttim ve örnekleri ve diyagramları buna göre güncelledim. Bu mimari tarz ve DDD hakkındaki yorumlarım hakkındaki yorumlar her zaman memnuniyetle karşılanacaktır.
Neden Altıgen Deniyor?
Altıgen mimari adı, bu mimarinin genellikle tasvir edilme biçiminden gelir:
Bu makalenin ilerleyen bölümlerinde neden altıgenlerin kullanıldığına döneceğiz. Bu mimari aynı zamanda portlar ve adaptörler (arkasındaki ana fikri daha iyi açıklayan) ve onion(soğan) mimarisi (nasıl katmanlı olduğu için) adlarına da giriyor.
Aşağıda "soğana" daha yakından bakacağız. Çekirdekle başlayacağız - domain modeli - ve sonra kendimizi, her seferinde bir katman olarak, adaptörlere ve onlarla etkileşime giren sistemlere ve istemcilere ulaşana kadar çalışacağız.
Altıgen ve Geleneksel Katmanlar
Altıgen mimarinin derinliklerine indiğimizde, daha geleneksel katmanlı mimariye birkaç benzerliği olduğunu göreceksiniz. Aslında, altıgen mimariyi katmanlı mimarinin bir evrimi olarak düşünebilirsiniz. Bununla birlikte, özellikle bir sistemin dış dünya ile nasıl etkileşime girdiğine dair bazı farklılıklar vardır. Bu farklılıkları daha iyi anlamak için katmanlı mimarinin bir özetiyle başlayalım:
İlke, sistemin birbiri üzerine yığılmış katmanlardan oluşmasıdır. Daha yüksek bir katman, daha düşük bir katmanla etkileşime girebilir ancak tersi olamaz. Tipik olarak, domaine dayalı katmanlı bir mimaride, en üstte UI katmanına sahip olursunuz. Bu katman da, bir domain katmanında yaşayan domain modeliyle etkileşime giren bir application servis katmanıyla etkileşime girer. En altta, veritabanı gibi harici sistemlerle iletişim kuran bir altyapı katmanımız var.
Altıgen sistemde, uygulama katmanının ve domain katmanının hemen hemen aynı olduğunu göreceksiniz. Bununla birlikte, UI katmanı ve altyapı katmanı çok farklı bir şekilde ele alınır. Nasıl olduğunu öğrenmek için okumaya devam edin.
Etki Alanı Modeli (Domain Model)
Altıgen mimarinin tam merkezinde, önceki makalede ele aldığımız taktik DDD yapı taşlarını kullanarak uygulanan alan modeli yatıyor. Tüm iş kararlarının alındığı, iş mantığının yaşadığı yer burasıdır. Bu aynı zamanda yazılımın en az değişeceğini umduğumuz en kararlı parçasıdır (tabii işin kendisi değişmedikçe).
Alan modeli, bu dizinin önceki iki makalesinin konusu olmuştur, bu yüzden artık burada ele almayacağız. Bununla birlikte, domain modeli tek başına, onunla etkileşim kurmanın bir yolu yoksa herhangi bir değer sağlamaz. Bunu yapmak için, "soğan" da bir sonraki katmana geçmemiz gerekiyor.
Uygulama Hizmetleri(Application Services)
Bir application servis, müşterilerin alan modeliyle etkileşime gireceği bir cephe görevi görür. Applicaiton servisleri aşağıdaki özelliklere sahiptir:
Durum bilgisi turmazlar (stateless)
Sistem güvenliğini uygularlar
Veritabanı işlemlerini kontrol ederler
İş operasyonlarını düzenlerler ancak herhangi bir iş kararı almazlar (yani herhangi bir iş mantığı içermezler)
Bunun ne anlama geldiğine daha yakından bakalım.
Altıgen ve Entity-Kontrol-Sınırı(Hexagonal vs. Entity-Control-Boundary)
Entity-Kontrol-Sınır modelini daha önce duyduysanız, altıgen mimariyi tanıdık bulacaksınız. Aggregate'lerinizi entity'ler(entities), domain servisleri , factory'leri ve repository'leri controller'lar(controllers) olarak ve applicaiton servislerini sınırlar(boundries) olarak düşünebilirsiniz.
Durum Bilgisizlik (Statelessness)
Bir application servis, istemcilerle etkileşime girerek değiştirilebilecek herhangi bir iç durumu korumaz. Bir işlemi gerçekleştirmek için gereken tüm bilgiler, applicaiton servis yönteminin girdi parametreleri olarak mevcut olmalıdır. Bu, sistemi daha basit, hata ayıklamayı ve ölçeklendirmeyi kolaylaştıracaktır.
Kendinizi tek bir iş süreci bağlamında birden çok application servis çağrısı yapmanız gereken bir durumda bulursanız, iş sürecini kendi sınıfında modelleyebilir ve uygulamanın servis metoduna bir girdi parametresi olarak bir örneğini iletebilirsini. Metod daha sonra sihrini yerine getirir ve diğer application servis yöntemlerine girdi olarak kullanılabilen iş süreci nesnesinin güncellenmiş bir örneğini döndürür:
Girdi Argümanı Olarak İş Süreci.
public class MyBusinessProcess {
// Current process state
}
public interface MyApplicationService {
MyBusinessProcess performSomeStuff(MyBusinessProcess input);
MyBusinessProcess performSomeMoreStuff(MyBusinessProcess input);
}
Ayrıca, iş süreci nesnesini mutable hale getirebilir ve application servis yönteminin(applicaiton service) nesnenin durumunu doğrudan değiştirmesine izin verebilirsiniz. Kişisel olarak bu yaklaşımı tercih etmiyorum çünkü istenmeyen yan etkilere yol açabileceğine inanıyorum, özellikle transaction rollback yapıldığında. Bu, application servisinin istemci tarafından nasıl çağrıldığına bağlıdır ve bu konuya daha sonra bağlantı noktaları(ports) ve bağdaştırıcılar(adaptors) hakkındaki bölümde bahsedilecektir.
Daha karmaşık ve uzun süreli iş süreçlerinin nasıl uygulanacağına dair ipuçları için Vernon'un kitabını okumanızı tavsiye ederim.
Güvenlik yaptırımı(Security Enforcement)
Application servis, mevcut kullanıcının söz konusu işlemi gerçekleştirmesine izin verilmesini sağlar. Teknik olarak, bunu her bir application servis yönteminin üst kısmında manuel olarak yapabilir veya AOP gibi daha karmaşık bir şey kullanabilirsiniz. Domain modeli içinde değil, applicaiton servis katmanında olduğu sürece güvenliğin nasıl uygulandığı önemli değildir.
Şimdi, bu neden önemli?
Bir uygulamada güvenlik hakkında konuştuğumuzda, yetkili erişime izin vermektense yetkisiz erişimi önlemeye daha fazla vurgu yapma eğilimindeyiz. Bu nedenle, sisteme eklediğimiz herhangi bir güvenlik kontrolü, esasen kullanımını zorlaştıracaktır. Bu güvenlik kontrollerini domain modeline eklersek kendimizi güvenlik kontrolleri eklendiğinde aklımıza gelmediği için önemli bir işlemi yapamayacağımız bir durumda bulabiliriz. Tüm güvenlik kontrollerini domain modelinin dışında tutarak, domain modeli ile istediğimiz şekilde etkileşim kurabildiğimiz için daha esnek bir sistem elde ediyoruz. Tüm istemcilerin zaten bir application servisinden geçmesi gerektiğinden sistem yine de güvenli olacaktır. Yeni bir application servisi oluşturmak, domain modelini değiştirmekten çok daha kolaydır.
Kod Örnekleri
Aşağıda, bir application servisinde güvenlik uygulamasının nasıl görünebileceğine dair iki Java örneği verilmiştir. Kod test edilmemiştir ve gerçek Java kodundan daha çok sözde kod olarak ele alınmalıdır.
Bildirime Dayalı(Declarative) Güvenlik Uygulaması
@Service
class MyApplicationService {
@Secured("ROLE_BUSINESS_PROCESSOR") //
public MyBusinessProcess performSomeStuff(MyBusinessProcess input) {
var customer = customerRepository.findById(input.getCustomerId()) //
.orElseThrow( () -> new CustomerNotFoundException(input.getCustomerId()));
var someResult = myDomainService.performABusinessOperation(customer); //
customer = customerRepository.save(customer);
return input.updateMyBusinessProcessWithResult(someResult); //
}
}
- Anatasyon, framework'e yalnızca ROLE_BUSINESS_PROCESSOR rolüne sahip kimliği doğrulanmış kullanıcıların yöntemi çağırmasına izin vermesi talimatını verir.
- Application servis(applicaiton service), domain modelindeki bir repodan bir domain model arar.
- Application servis, aggregate'i domain modelindeki bir domain servisine(domain service) geçirerek sonucu (ne olursa olsun) depolar.
- Application servisi, iş süreci nesnesini güncellemek için domain servisinin sonucunu kullanır ve aynı uzun süreli işleme katılan diğer applicaiton servis yöntemlerine aktarılabilmesi için onu döndürür.
Manuel Güvenlik Uygulaması
@Service
class MyApplicationService {
public MyBusinessProcess performSomeStuff(MyBusinessProcess input) {
// We assume SecurityContext is a thread-local class that contains information
// about the current user.
if (!SecurityContext.isLoggedOn()) { //
throw new AuthenticationException("No user logged on");
}
if (!SecurityContext.holdsRole("ROLE_BUSINESS_PROCESSOR")) { //
throw new AccessDeniedException("Insufficient privileges");
}
var customer = customerRepository.findById(input.getCustomerId())
.orElseThrow( () -> new CustomerNotFoundException(input.getCustomerId()));
var someResult = myDomainService.performABusinessOperation(customer);
customer = customerRepository.save(customer);
return input.updateMyBusinessProcessWithResult(someResult);
}
}
- Gerçek bir uygulamada, muhtemelen bir kullanıcı oturum açmamışsa istisnayı atan yardımcı yöntemler oluşturursunuz. Neyin kontrol edilmesi gerektiğini göstermek için bu örneğe yalnızca daha ayrıntılı bir versiyon ekledim.
- Önceki durumda olduğu gibi, yalnızca ROLE_BUSINESS_PROCESSOR rolüne sahip kullanıcıların yöntemi çağırmasına izin verilir.
Transaction yönetimi (Transaction Management)
Her applicaiton servis yöntemi, temeldeki veri deposunun işlemleri kullanıp kullanmadığına bakılmaksızın, kendi başına tek bir işlem oluşturacak şekilde tasarlanmalıdır. Bir application servis yöntemi başarılı olursa, işlemi tersine çeviren başka bir application servisini açıkça çağırmak dışında bunu geri almanın bir yolu yoktur (böyle bir yöntem varsa bile).
Kendinizi aynı işlem içinde birden çok application servisi yöntemini çağırmak istediğiniz bir durumda bulursanız, application servisinizin ayrıntı düzeyinin doğru olup olmadığını kontrol etmelisiniz. Belki de application servisinizin yaptığı bazı şeyler aslında bunun yerine domain servislerde olmalıdır? Sisteminizi güçlü tutarlılık yerine nihai tutarlılığı kullanacak şekilde yeniden tasarlamayı da düşünmeniz gerekebilir (bununla ilgili daha fazla bilgi için lütfen taktik domaine dayalı tasarım hakkındaki önceki makaleye bakın).
Teknik olarak, işlemleri application servisi yöntemi içerisinde manuel olarak halledebilir veya Spring ve Java EE gibi frameworkler ve platformlar tarafından sunulan anatasyonları kullanabilirsiniz.
Kod Örnekleri:
İşte bir application servisindeki işlem yönetiminin nasıl görünebileceğine dair iki Java örneği. Kod test edilmemiştir ve gerçek Java kodundan daha çok sözde kod olarak ele alınmalıdır.
Bildirime Dayalı(Declarative) Transaction Yönetimi
@Service
class UserAdministrationService {
@Transactional //
public void resetPassword(UserId userId) {
var user = userRepository.findByUserId(userId); //
user.resetPassword(); //
userRepository.save(user);
}
}
- Framework, tüm yöntemin tek bir işlem içinde çalıştığından emin olacaktır. Bir istisna atılırsa, işlem geri alınır. Aksi takdirde, yöntem geri döndüğünde kesinleşir.
- Application servisi, Kullanıcı aggregate kökünü bulmak için domain modelinde bir repository çağırır.
- Application servisi, Kullanıcı aggreagte kökünde bir iş yöntemini çağırır.
Manuel Transaction Management
@Service
class UserAdministrationService {
@Transactional
public void resetPassword(UserId userId) {
var tx = transactionManager.begin(); //
try {
var user = userRepository.findByUserId(userId);
user.resetPassword();
userRepository.save(user);
tx.commit(); //
} catch (RuntimeException ex) {
tx.rollback(); //
throw ex;
}
}
}
- Tranaction yöneticisi application servisine enjekte edilmiştir, böylece servis yöntemi açıkça yeni bir işlem başlatabilir.
- Her şey çalışırsa, işlem parola sıfırlandıktan sonra gerçekleştirilir.
- Bir hata oluşursa, işlem geri alınır ve istisna yeniden oluşturulur.
Orkestrasyon
İyi bir application servisi tasarlamanın belki de en zor kısmı, düzenlemeyi doğru yapmaktır. Bunun nedeni, yalnızca düzenleme yaptığınızı düşünseniz bile application servisine kazara iş mantığı eklemediğinizden emin olmanız gerektiğidir. Peki bu bağlamda orkestrasyon ne anlama geliyor?
Düzenleme ile, doğru domain nesnelerini doğru sırada aramak ve çağırmak, doğru girdi parametrelerini geçirmek ve doğru çıktıyı döndürmek demek istiyorum. En basit haliyle, bir application servisi bir kümeyi bir kimliğe göre arayabilir, bu kümede bir yöntemi çağırabilir, kaydedebilir ve geri dönebilir. Bununla birlikte, daha karmaşık durumlarda, yöntemin birden çok kümeye bakması, domain servisleriyle etkileşime girmesi, girdi doğrulaması yapması vb. Gerekebilir. Kendinizi uzun application servisi yöntemleri yazarken bulursanız, kendinize aşağıdaki soruları sormalısınız:
Yöntem bir iş kararı mı veriyor yoksa domain modelinden karar vermesini mi istiyor?
Kodun bir kısmı domain olay dinleyicilerine (domain event listeners) taşınmalı mı?
Bununla birlikte, bir application servisi yönteminde biten bir iş mantığına sahip olmak dünyanın sonu değil. Alan modeline hala oldukça yakındır ve iyi bir şekilde kapsüllenmiştir ve daha sonra alan modelini yeniden düzenlemek oldukça kolay olacaktır. Sizin için hemen anlaşılmamışsa, bir şeyin alan modeline mi yoksa application servistine mi girmesi gerektiğini düşünerek çok fazla değerli zaman kaybetmeyin.
Kod Örnekleri
İşte tipik bir orkestrasyonun nasıl görünebileceğine dair bir Java örneği. Kod test edilmemiştir ve gerçek Java kodundan daha çok sözde kod olarak ele alınmalıdır.
Birden Çok domain Nesnesini İçeren Düzenleme
@Service
class CustomerRegistrationService {
@Transactional //
@PermitAll //
public Customer registerNewCustomer(CustomerRegistrationRequest request) {
var violations = validator.validate(request); //
if (violations.size() > 0) {
throw new InvalidCustomerRegistrationRequest(violations);
}
customerDuplicateLocator.checkForDuplicates(request); //
var customer = customerFactory.createNewCustomer(request); //
return customerRepository.save(customer); //
}
}
- Application servisti yöntemi bir transaction içinde çalışır.
- Application servisi yöntemine herhangi bir kullanıcı tarafından erişilebilir.
- Gelen kayıt talebinin gerekli tüm bilgileri içerip içermediğini kontrol etmek için bir JSR-303 doğrulayıcı çağırıyoruz. İstek geçersizse, kullanıcıya geri bildirilecek bir istisna atarız.
- Veritabanında aynı bilgilere sahip bir müşteri olup olmadığını kontrol edecek bir domain servisini çağırıyoruz. Durum böyleyse, domain servisi kullanıcıya geri yayılacak bir istisna (burada gösterilmemiştir) atar.
- Kayıt talebi nesnesinden gelen bilgilerle yeni bir Müşteri agrregate'i oluşturacak bir domain factory'si çağırıyoruz.
- Müşteriyi kaydetmek için bir domain repository'si çağırırız ve yeni oluşturulan ve kaydedilen müşteri aggregate root döndürürüz.
Domain Olay Dinleyicileri (Domain Event Listeners)
Taktiksel domaine dayalı tasarımla ilgili bir önceki makalede, domain olayları ve domain olay dinleyicileri hakkında konuştuk. Bununla birlikte, domain olay dinleyicilerinin genel sistem mimarisine nerede uyduğundan bahsetmedik. Önceki makaleden hatırlıyoruz ki, bir domain olay dinleyicisi, olayı ilk etapta yayınlayan yöntemin sonucunu etkilememelidir. Pratikte bu, bir domain olay dinleyicisinin kendi işlemi içinde çalışması gerektiği anlamına gelir.
Bu nedenle, domain olay dinleyicilerini bir istemci tarafından değil, bir domain olayı tarafından başlatılan özel bir applicaiton servis türü olarak görüyorum. Başka bir deyişle: domain olay dinleyicileri, domain modelinin içine değil applicaiton servis katmanına aittir. Bu aynı zamanda bir domain olay dinleyicisinin herhangi bir iş mantığı içermemesi gereken bir düzenleyici olduğu anlamına gelir. Belirli bir domain olayı yayınlandığında ne olması gerektiğine bağlı olarak, birden fazla ileriye giden yol varsa onunla ne yapılacağına karar veren ayrı bir domain servisi oluşturmanız gerekebilir.
Şöyle ki, önceki makaledeki agregalarla ilgili bölümde, bazen aynı işlem içinde birden fazla agregayı değiştirmenin, toplam tasarım yönergelerine aykırı olsa da, haklı görülebileceğinden bahsetmiştim. Ayrıca bunun tercihen domain olayları aracılığıyla yapılması gerektiğinden de bahsetmiştim. Bu gibi durumlarda, domain olay dinleyicileri mevcut işleme katılmak zorunda kalacak ve bu nedenle etkinliği yayınlayan yöntemin sonucunu etkileyerek hem domain olayları hem de applicaiton servisleri için tasarım yönergelerini bozabilirler. Bunu bilerek yaptığınız ve gelecekte karşılaşabileceğiniz sonuçların farkında olduğunuz sürece bu dünyanın sonu değildir. Bazen sadece pragmatik olmanız gerekir.
Giriş ve çıkış (Input and Output)
Applicaiton servislerini tasarlarken önemli bir karar, hangi verilerin (metod parametreleri) tüketileceğine ve hangi verilerin döndürüleceğine karar vermektir. Üç seçeneğiniz var:
- Entityleri ve değer nesnelerini doğrudan domain modelinden kullanın.
- Ayrı Veri Aktarım Nesneleri (DTO'lar) kullanın.
- Yukarıdaki ikisinin birleşimi olan domain payload Nesnelerini (DPO'lar) kullanın.
Her alternatifin kendi artıları ve eksileri vardır, bu nedenle her birine daha yakından bakalım.
Varlıklar ve Agregalar (Entities and Aggregates)
İlk alternatifte, applicaiton servisleri tüm agregaları (veya bunların parçalarını) döndürür. Client onlarla istediğini yapabilir ve değişiklikleri kaydetme zamanı geldiğinde, agregalar(veya bunların parçaları) parametre olarak applicaiton servislere geri gönderilir.
Bu alternatif, domain modeli anemik olduğunda (yani yalnızca veri içerdiğinde ve iş mantığı olmadığında) ve agregalar küçük ve kararlı olduğunda (yakın gelecekte pek değişmesi muhtemel olmadığı gibi) en iyi şekilde çalışır.
Ayrıca, istemcinin sisteme REST veya SOAP üzerinden erişmesi durumunda da çalışır ve agregalar kolayca JSON veya XML ve geri serileştirilebilir. Bu durumda, istemciler aslında agregalarınıza doğrudan değil, tamamen farklı bir dilde uygulanabilecek bir JSON veya toplamın XML temsiliyle etkileşimde bulunacaktır. Clientin bakış açısından, agregalar sadece DTO'lardır.
Bu alternatifin avantajları şunlardır:
- Zaten sahip olduğunuz sınıfları kullanabilirsiniz
- Domian nesneleri ve DTO'lar arasında dönüştürme yapmaya gerek yoktur.
Dezavantajlar:
- Domain modelini doğrudan istemcilerle eşleştirir. Domain modeli değişirse, clientleriniz de değiştirmeniz gerekir.
- Kullanıcı girişini nasıl doğrulayacağınıza dair kısıtlamalar getirir (bununla ilgili daha sonra daha fazla bahsedeceğiz).
- Agregalarınız, clientin agregayı tutarsız bir duruma getiremeyeceği veya izin verilmeyen bir işlemi gerçekleştiremeyeceği şekilde tasarlamalısınız.
- Bir toplu (JPA) içindeki entitylerin geç yüklenmesiyle ilgili sorunlarla karşılaşabilirsiniz.
Şahsen ben bu yaklaşımdan elimden geldiğince kaçınmaya çalışıyorum.
Veri Aktarım Nesneleri (Data Transfer Objects)
İkinci alternatifte, applicaiton servisleri veri aktarım nesnelerini tüketir ve döndürür. DTO'lar, domain modelindeki entitylere karşılık gelebilir, ancak daha sık olarak belirli bir applicaiton servisti veya hatta belirli bir applicaiton servisi yöntemi (istek ve yanıt nesneleri gibi) için tasarlanmıştır. applicaiton servisi daha sonra verileri DTO'lar ve domain nesneleri arasında ileri geri taşımaktan sorumludur.
Bu alternatif, domain modeli iş mantığı açısından çok zengin olduğunda, agregalar karmaşık olduğunda veya istemci API'sini olabildiğince istikrarlı tutarken domain modelinin çok değişmesi beklendiğinde en iyi şekilde çalışır.
Bu alternatifin avantajları şunlardır:
- İstemciler, domain modelinden ayrıştırılarak istemcileri değiştirmek zorunda kalmadan onu geliştirmeyi kolaylaştırır.
- Yalnızca gerçekte ihtiyaç duyulan veriler istemciler ve uygulama hizmetleri arasında aktarılır, bu da performansı artırır (özellikle istemci ve uygulama hizmeti dağıtılmış bir ortamda bir ağ üzerinden iletişim kuruyorsa).
- Domain modeline erişimi kontrol etmek, özellikle yalnızca belirli kullanıcıların belirli agrega yöntemlerini başlatmasına veya belirli toplu öznitelik değerlerini görüntülemesine izin veriliyorsa daha kolay hale gelir.
- Yalnızca applicaiton servisleri, aktif işlemlerin içindeki agregalarla etkileşime girecektir. Bu, bir agrega (JPA) içindeki entitylerin lazy yüklemesini kullanabileceğiniz anlamına gelir.
- DTO'lar arayüzlerse ve sınıflar değilse, daha da fazla esneklik elde edersiniz.
Dezavantajlar:
- Bakım için yeni bir DTO sınıfı seti alırsınız.
- Verileri DTO'lar ve agregalar arasında ileri geri taşımanız gerekir. DTO'lar ve entitiyler yapı olarak neredeyse benzer ise, bu özellikle sıkıcı olabilir. Bir takımda çalışıyorsanız, DTO'lar ve agregaların neden ayrılması gerektiğine dair iyi bir açıklamaya ihtiyacınız vardır.
Şahsen, çoğu durumda işe başladığım yaklaşım budur. Bazen, bakacağımız bir sonraki alternatif olan DTO'larımı DPO'lara dönüştürmek oluyor.
Domain Yük Nesneleri(Domain Payload Objects)
Üçüncü alternatifte, applicaiton servisleri domain yük nesnelerini tüketir ve döndürür. Domain yük nesnesi, domain modelinin farkında olan ve domain nesnelerini içerebilen bir veri aktarım nesnesidir. Bu, esasen ilk iki alternatifin bir kombinasyonudur.
Bu alternatif, domain modelinin anemik olduğu, agregaların küçük ve kararlı olduğu ve birden çok farklı agregayı içeren bir işlem uygulamak istediğiniz durumlarda en iyi sonucu verir. Kişisel olarak, DPO'ları girdi nesnelerinden çok çıktı nesneleri olarak kullandığımı söyleyebilirim. Bununla birlikte, DPO'larda domain nesnelerinin kullanımını, yalnızca mümkünse nesnelere değer vermek için sınırlandırmaya çalışıyorum.
Bu alternatifin avantajları şunlardır:
- Her şey için DTO sınıfları oluşturmanıza gerek yoktur. Bir domain nesnesini doğrudan istemciye iletmek yeterince iyidir, bunu yaparsınız. Özel bir DTO'ya ihtiyacınız olduğunda, bir tane oluşturursunuz. İkisine de ihtiyacınız olduğunda ikisini de kullanırsınız.
Dezavantajlar:
- İlk alternatifle aynı. Dezavantajlar, yalnızca DPO'ların içine immutable değer nesnelerini dahil ederek hafifletilebilir.
Kod Örnekleri
Sırasıyla DTO'ları ve DPO'ları kullanmanın iki Java örneği. DTO örneği, varlığı doğrudan döndürmektense bir DTO kullanmanın daha mantıklı olduğu bir kullanım durumunu gösterir: Entity özelliklerinin yalnızca bir kısmına ihtiyaç vardır ve entityde var olmayan bilgileri eklememiz gerekir. DPO örneği, DPO kullanmanın mantıklı olduğu bir kullanım durumunu gösterir: Bir şekilde birbiriyle ilişkili birçok farklı agregayı eklememiz gerekir.
Kod test edilmemiştir ve gerçek Java kodundan daha çok sözde kod olarak ele alınmalıdır.
Veri Aktarım Nesnesi Örneği
public class CustomerListEntryDTO {
private CustomerId id;
private String name;
private LocalDate lastInvoiceDate;
Getters and setters omitted
}
@Service
public class CustomerListingService {
@Transactional
public List getCustomerList() {
var customers = customerRepository.findAll();
var dtos = new ArrayList();
for (var customer : customers) {
var lastInvoiceDate = invoiceService.findLastInvoiceDate(customer.getId());
dto = new CustomerListEntryDTO();
dto.setId(customer.getId());
dto.setName(customer.getName());
dto.setLastInvoiceDate(lastInvoiceDate);
dtos.add(dto);
}
return dto;
}
} - Veri Aktarım Nesnesi, herhangi bir iş mantığı içermeyen bir veri yapısıdır. Bu özel DTO, yalnızca müşteri adını ve son fatura tarihini göstermesi gereken bir kullanıcı arabirimi liste görünümünde kullanılmak üzere tasarlanmıştır.
- Veritabanından tüm müşteri kümelerini arıyoruz. Gerçek dünyadaki bir uygulamada, bu yalnızca müşterilerin bir alt kümesini döndüren sayfalandırılmış bir sorgu olacaktır.
- Son fatura tarihi müşteri varlığında saklanmaz, bu nedenle bizim için aramak için bir domain servisini çağırmamız gerekir.
- DTO örneğini oluşturuyoruz ve onu verilerle dolduruyoruz.
Domain Yük Nesnesi Örneği
public class CustomerInvoiceMonthlySummaryDPO { //
private Customer customer;
private YearMonth month;
private Collection invoices;
// Getters and setters omitted
}
@Service
public class CustomerInvoiceSummaryService {
public CustomerInvoiceMontlySummaryDPO getMonthlySummary(CustomerId customerId, YearMonth month) {
var customer = customerRepository.findById(customerId); //
var invoices = invoiceRepository.findByYearMonth(customerId, month); //
var dpo = new CustomerInvoiceMonthlySummaryDPO(); //
dpo.setCustomer(customer);
dpo.setMonth(month);
dpo.setInvoices(invoices);
return dpo;
}
}
- Domain Yük Nesnesi, hem domain nesnelerini (bu durumda entityler) hem de ek bilgileri (bu durumda yıl ve ay) içeren herhangi bir iş mantığı olmayan bir veri yapısıdır.
- Müşterinin agrega kökünü repodan alıyoruz.
- Müşterinin belirtilen yıl ve aya ait faturalarını alıyoruz.
- DPO örneğini oluşturup verilerle dolduruyoruz.
Giriş Doğrulama (Input Validation)
Daha önce bahsettiğimiz gibi, bir agrega her zaman tutarlı bir durumda olmalıdır. Bu, diğer şeylerin yanı sıra, bir agreganın durumunu değiştirmek için kullanılan tüm girdileri uygun şekilde doğrulamamız gerektiği anlamına gelir. Bunu nasıl ve nerede yapıyoruz?
Bir kullanıcı deneyimi perspektifinden, kullanıcı arayüzü, verilerin geçersiz olması durumunda kullanıcının bir işlemi bile gerçekleştirememesi için doğrulama içermelidir. Ancak, altıgen bir sistemde sadece kullanıcı arabirimi doğrulamasına güvenmek yeterince iyi değildir. Bunun nedeni, kullanıcı arayüzünün sisteme potansiyel olarak birçok giriş noktasından biri olmasıdır. Bir REST uç noktası, domain modeline herhangi bir çöpün geçmesine izin veriyorsa, kullanıcı arabiriminin verileri doğru şekilde doğrulamasına yardımcı olmaz.
Girdi doğrulama hakkında düşünürken aslında iki farklı doğrulama türü vardır: format doğrulama ve içerik doğrulama. Formatı doğrularken, belirli türlerdeki belirli değerlerin belirli kurallara uygun olup olmadığını kontrol ederiz. Örneğin. bir sosyal güvenlik numarasının belirli bir modelde olması beklenmektedir. İçeriği doğruladığımızda, zaten iyi biçimlendirilmiş bir veri parçasına sahibiz ve bu verilerin mantıklı olup olmadığını kontrol etmekle ilgileniyoruz. Örneğin. İyi biçimlendirilmiş bir sosyal güvenlik numarasının gerçekte gerçek bir kişiye karşılık gelip gelmediğini kontrol etmek isteyebiliriz. Bu doğrulamaları farklı şekillerde uygulayabilirsiniz, bu sebeblerden dolayı daha yakından bakalım.
Biçim Doğrulaması (Format Validation)
Domain modelinizde ilkel türlerin (dizeler veya tamsayılar gibi) etrafına sarılmış çok sayıda değer nesnesi kullanıyorsanız (bunu kişisel olarak yapma eğilimindeyim), o zaman biçim doğrulamasını doğrudan değer nesnesi oluşturucunuza oluşturmak mantıklıdır. . Başka bir deyişle, örneğin oluşturulması mümkün olmamalıdır. iyi biçimlendirilmiş bir bağımsız değişkeni iletmeden bir EmailAddress veya SocialSecurityNumber örneği. Bu, geçerli verileri girmenin bilinen birden çok yolu varsa (örneğin, bir telefon numarası girerken bazı kişiler sayıyı gruplara ayırmak için boşluklar veya kısa çizgiler kullanabilirken diğerleri oluşturucu içinde bazı ayrıştırma ve temizleme işlemleri yapabileceğiniz gibi ek bir avantaja sahiptir hiçbir boşluk kullanmayın).
Şimdi, değer nesneleri geçerli olduğunda, onları kullanan entityleri nasıl doğrularız? Java geliştiricileri için kullanılabilen iki seçenek vardır.
İlk seçenek, doğrulamayı kurucularınıza, fabrikalarınıza ve ayarlayıcı yöntemlerinize eklemektir. Buradaki fikir, bir kümeyi tutarsız bir duruma getirmenin bile mümkün olmaması gerektiğidir: tüm gerekli alanlar kurucuda doldurulmalıdır, gerekli alanların ayarlayıcıları boş parametreleri kabul etmeyecektir, diğer ayarlayıcılar yanlış bir değeri kabul etmeyecektir. format veya uzunluk, vb. İş mantığı açısından çok zengin olan alan modelleriyle çalışırken kişisel olarak bu yaklaşımı kullanma eğilimindeyim. Domain modelini çok sağlam kılar, ancak aynı zamanda pratik olarak sizi istemciler ve applicaiton servisleri arasında DTO'ları kullanmaya zorlar çünkü bir UI'ye düzgün bir şekilde bağlanmak hemen hemen imkansızdır.
İkinci seçenek, Java Bean Doğrulamasını (JSR-303) kullanmaktır. Tüm alanlara ek açıklamalar yerleştirin ve applicaiton servisinizin, onunla başka bir şey yapmadan önce agregayı Doğrulayıcı aracılığıyla çalıştırdığından emin olun. Ben kişisel olarak bu yaklaşımı anemik alan modelleriyle çalışırken kullanma eğilimindeyim. Agreganın kendisi kimsenin onu tutarsız bir duruma sokmasını engellemese de, bir depodan alınmış veya doğrulamadan geçmiş tüm agregaların tutarlı olduğunu güvenle varsayabilirsiniz.
Domain modelinizdeki ilk seçeneği ve gelen DTO'larınız veya DPO'larınız için Java Bean Doğrulamasını kullanarak her iki seçeneği de birleştirebilirsiniz.
İçerik Doğrulama (Content Validation)
İçerik doğrulamasının en basit durumu, aynı agregada iki veya daha fazla birbirine bağlı özniteliğin geçerli olduğundan emin olmaktır (örneğin, bir attribute ayarlanmışsa, diğeri boş olmalıdır ve bunun tersi de geçerlidir). Bunu doğrudan entity sınıfının kendisine uygulayabilir veya sınıf düzeyinde bir Java Bean Doğrulama kısıtlaması kullanabilirsiniz. Bu tür içerik doğrulaması, aynı mekanizmaları kullandığı için format doğrulaması yapılırken ücretsiz olarak gelecektir.
Daha karmaşık bir içerik doğrulama durumu, bir yerde bir arama listesinde belirli bir değerin var olduğunu (veya olmadığını) kontrol etmek olabilir. Bu büyük ölçüde applicaiton servsinin sorumluluğundadır. Herhangi bir iş veya kalıcılık işleminin devam etmesine izin vermeden önce, application servisi aramayı gerçekleştirmeli ve gerekirse bir istisna atmalıdır. Bu, entityler taşınabilir domain nesneleri olduğundan, arama için gereken nesneler tipik olarak statik olduğundan entitylerinize yerleştirmek isteyeceğiniz bir şey değildir (hareketli ve statik nesneler hakkında daha fazla bilgi için taktik DDD hakkındaki önceki makaleye bakın).
İçerik doğrulamasının en karmaşık durumu, tüm bir agregayı bir dizi iş kuralına göre doğrulamak olacaktır. Bu durumda sorumluluk, domain modeli ve application servisi arasında bölünür. Doğrulamanın kendisinin gerçekleştirilmesinden bir domain servisi sorumlu olabilir, ancak domain servisini başlatmaktan application servisi sorumlu olacaktır.
Kod Örnekleri
Burada, doğrulama işleminin üç farklı yoluna bakacağız. İlk durumda, bir değer nesnesinin (bir telefon numarası) yapıcısının içinde biçim doğrulaması gerçekleştirmeye bakacağız. İkinci durumda, yerleşik doğrulama olan bir varlığa bakacağız, böylece nesneyi ilk etapta tutarsız bir duruma sokmak mümkün olmaz. Üçüncü ve son durumda, aynı varlığa bakacağız ancak JSR-303 doğrulaması kullanılarak uygulanacağız. Bu, nesneyi tutarsız bir duruma getirmeyi mümkün kılar, ancak bu şekilde veritabanına kaydetmemeyi mümkün kılar.
Biçim Doğrulamalı Değer Nesnesi
public class PhoneNumber implements ValueObject {
private final String phoneNumber;
public PhoneNumber(String phoneNumber) {
Objects.requireNonNull(phoneNumber, "phoneNumber must not be null"); //
var sb = new StringBuilder();
char ch;
for (int i = 0; i lt phoneNumber.length(); ++i) {
ch = phoneNumber.charAt(i);
if (Character.isDigit(ch)) { //
sb.append(ch);
} else if (!Character.isWhitespace(ch) && ch != '(' && ch != ')' && ch != '-' && ch != '.') { //
throw new IllegalArgument(phoneNumber + " is not valid");
}
}
if (sb.length() == 0) { //
throw new IllegalArgumentException("phoneNumber must not be empty");
}
this.phoneNumber = sb.toString();
}
@Override
public String toString() {
return phoneNumber;
}
// Equals and hashCode omitted
}
İlk olarak, giriş değerinin boş olmadığını kontrol ederiz.
Gerçekte sakladığımız son telefon numarasına yalnızca rakamları dahil ediyoruz. Uluslararası telefon numaraları için, ilk karakter olarak bir '+' işaretini de desteklemeliyiz, ancak bunu okuyucuya bir alıştırma olarak bırakacağız.
İnsanların telefon numaralarında sıklıkla kullandıkları beyaz boşluklara ve belirli özel karakterlere izin veririz, ancak yok sayarız.
Son olarak tüm temizlik bittiğinde telefon numarasının boş olmadığını kontrol ediyoruz.
Yerleşik Doğrulamalı Entity
public class Customer implements Entity {
// Fields omitted
public Customer(CustomerNo customerNo, String name, PostalAddress address) {
setCustomerNo(customerNo); //
setName(name);
setPostalAddress(address);
}
public setCustomerNo(CustomerNo customerNo) {
this.customerNo = Objects.requireNonNull(customerNo, "customerNo must not be null");
}
public setName(String name) {
Objects.requireNonNull(nanme, "name must not be null");
if (name.length() lt 1 || name.length > 50) { //
throw new IllegalArgumentException("Name must be between 1 and 50 characters");
}
this.name = name;
}
public setAddress(PostalAddress address) {
this.address = Objects.requireNonNull(address, "address must not be null");
}
}- Setter yöntemlerinde uygulanan doğrulamayı gerçekleştirmek için kurucudan setterları çağırırız. Bir alt sınıfın bunlardan herhangi birini geçersiz kılmaya karar vermesi durumunda, bir kurucudan geçersiz kılınabilen yöntemleri çağırmanın küçük bir riski vardır. Bu durumda, setter yöntemlerini final olarak işaretlemek daha iyi olacaktır, ancak bazı kalıcılık çerçevelerinin bununla ilgili bir sorunu olabilir. Sadece ne yaptığınızı bilmeniz lazım.
- Burada bir stringin uzunluğunu kontrol ediyoruz. Her müşterinin bir adı olması gerektiğinden, alt sınır bir iş gereksinimidir. Bu durumda veritabanı, yalnızca 50 karakterlik stringleri depolamasına izin veren bir şemaya sahip olduğundan, üst düzey bir veritabanı gereksinimidir. Doğrulamayı buraya zaten ekleyerek, veritabanına çok uzun stringler eklemeye çalıştığınızda daha sonraki bir aşamada can sıkıcı SQL hatalarını önleyebilirsiniz.
JSR-303 Doğrulamalı Entity
public class Customer implements Entity {
@NotNull (1)
private CustomerNo customerNo;
@NotBlank (2)
@Size(max = 50) (3)
private String name;
@NotNull
private PostalAddress address;
// Setters omitted
}
- Bu anatasyon, entity kaydedildiğinde müşteri numarasının null olmamasını sağlar.
- Bu anatasyon, entity kaydedildiğinde adın boş veya null olmamasını sağlar.
- Bu anatasyon, entity kaydedildiğinde adın 50 karakterden uzun olmamasını sağlar.
Boyut Önemli mi?
Portlara ve adaptörlere geçmeden önce kısaca bahsetmek istediğim bir şey daha var. Tüm facede'lerde olduğu gibi, çok fazla şey bilen ve çok şey yapan büyük tanrı sınıflarına dönüşen application servsilerin her zaman mevcut bir riski vardır. Bu tür sınıfları okumak ve sürdürmek genellikle çok büyük oldukları için zordur.
Peki application servsilerini nasıl küçük tutarsınız? İlk adım, elbette çok büyük büyüyen bir servisi daha küçük servislere bölmek. Ancak bunda da bir risk var. Durumların, geliştiricilerin aralarındaki farkın ne olduğunu veya hangi servise hangi yöntemin girmesi gerektiğini bilmediği kadar benzer iki servis olduğunu gördüm. Sonuç, servis yöntemlerinin iki ayrı servis sınıfına dağılmış olması ve hatta bazen iki kez (her servisde bir kez), ancak farklı geliştiriciler tarafından uygulanmasıydı.
application servsilerini tasarlarken, onları olabildiğince tutarlı hale getirmeye çalışıyorum. CRUD uygulamalarında bu, agrega başına bir application servsi anlamına gelebilir. Daha fazla domaine dayalı uygulamalarda bu, iş süreci başına bir application servisi veya hatta belirli kullanım durumları veya kullanıcı arabirimi görünümleri için ayrı servisler anlamına gelebilir.
Adlandırma, application servsleri tasarlarken çok iyi bir kılavuzdur. Application servslerinizi, ilgilendikleri agregaların aksine yaptıklarına göre adlandırmaya çalışın. Örneğin. EmployeeCrudService veya EmploymentContractTerminationUsecase, EmployeeService'ten çok daha iyi isimlerdir ve bu da herhangi bir anlama gelebilir. Ayrıca adlandırma kurallarınızı düşünmek için biraz zaman ayırın: tüm servislerinizi gerçekten Service son ekiyle sonlandırmanız gerekiyor mu? Bazı durumlarda Usecase veya Orchestrator gibi son ekleri kullanmak veya hatta soneki tamamen dışarıda bırakmak daha mantıklı olur mu?
Son olarak, komut tabanlı uygulama servislerinden bahsetmek istiyorum. Bu durumda, her application servis modelini, karşılık gelen bir komut işleyiciye sahip bir komut nesnesi olarak modellersiniz. Bu, her application servisinin tam olarak bir komutu işleyen tam olarak bir yöntem içerdiği anlamına gelir. Özel komutlar veya komut işleyicileri oluşturmak için polimorfizmi kullanabilirsiniz. Bu yaklaşım, çok sayıda küçük sınıfla sonuçlanır ve özellikle kullanıcı arabirimleri doğası gereği komut güdümlü olan veya istemcilerin bir ileti kuyruğu (MQ) veya kurumsal hizmet veriyolu gibi bir tür ileti mekanizması aracılığıyla uygulama hizmetleriyle etkileşime girdiği uygulamalarda yararlıdır. ESB).
Kod Örnekleri
Size Tanrı sınıfının neye benzediğine dair bir örnek vermeyeceğim çünkü bu çok fazla yer kaplar. Ayrıca, bir süredir bu meslekte olan çoğu geliştiricinin bu tür sınıflardan adil bir pay aldığını düşünüyorum. Bunun yerine, komut tabanlı bir uygulama hizmetinin nasıl görünebileceğine dair bir örneğe bakacağız. Kod test edilmemiştir ve gerçek Java kodundan daha çok sözde kod olarak ele alınmalıdır.
Komut Tabanlı Uygulama Hizmetleri
public interface Command { //
}
public interface CommandHandler, R/> { //
R handleCommand(C command);
}
public class CommandGateway { //
// Fields omitted
public , R/> R handleCommand(C command) {
var handler = commandHandlers.findHandlerFor(command)
.orElseThrow(() -> new IllegalStateException("No command handler found"));
return handler.handleCommand(command);
}
}
public class CreateCustomerCommand implements Command { //
private final String name;
private final PostalAddress address;
private final PhoneNumber phone;
private final EmailAddress email;
// Constructor and getters omitted
}
public class CreateCustomerCommandHandler implements CommandHandler { //
@Override
@Transactional
public Customer handleCommand(CreateCustomerCommand command) {
var customer = new Customer();
customer.setName(command.getName());
customer.setAddress(command.getAddress());
customer.setPhone(command.getPhone());
customer.setEmail(command.getEmail());
return customerRepository.save(customer);
}
}
- Komut arayüzü, komutun sonucunu (çıktısını) da gösteren bir işaret arayüzüdür. Komutun çıkışı yoksa, sonuç Void olabilir.
- CommandHandler arabirimi, belirli bir komutu nasıl işleyeceğini (gerçekleştireceğini) ve sonucu nasıl döndüreceğini bilen bir sınıf tarafından uygulanır.
- İstemciler, tek tek komut işleyicileri aramak zorunda kalmamak için bir CommandGateway ile etkileşime girer. Ağ geçidi, mevcut tüm komut işleyicileri ve herhangi bir komuta göre doğru olanı nasıl bulacağını bilir. İşleyicileri aramak için kullanılan kod, işleyicileri kaydetmeye yönelik temel mekanizmaya bağlı olduğundan, örnekte dahil edilmemiştir.
- Her komut, Komut arayüzünü uygular ve komutu gerçekleştirmek için gerekli tüm bilgileri içerir. Komutlarımı yerleşik doğrulama ile değişmez hale getirmeyi seviyorum, ancak bunları değiştirilebilir ve JSR-303 doğrulamasını da kullanabilirsiniz. Hatta komutlarınızı arayüz olarak bırakabilir ve maksimum esneklik için istemcilerin kendilerinin uygulamasına izin verebilirsiniz.
- Her komutun, komutu gerçekleştiren ve sonucu döndüren kendi işleyicisi vardır.
Bağlantı Noktaları ve Adaptörler (Ports And Adaptors)
Şimdiye kadar domaini ve onu çevreleyen ve onunla etkileşime giren application servisleri tartıştık. Ancak, istemcilerin onları çağırmasının bir yolu yoksa ve portların ve adaptörlerin resme girmediği bu yerde, bu application servisleri tamamen yararsızdır.
Port Nedir?
Port, belirli bir amaç veya protokol için tasarlanmış, sistem ile dış dünya arasındaki bir arayüzdür. Portları yalnızca dış istemcilerin sisteme erişmesine izin vermek için değil, aynı zamanda sistemin harici sistemlere erişmesine izin vermek için de kullanılır.
Artık portlar ağ portları olarak ve protokolleri HTTP gibi ağ protokolleri olarak düşünmeye başlamak kolaydır. Bu hatayı ben kendim yaptım ve hatta Vernon bunu kitabındaki en az bir örnekte yapıyor. Ancak, Vernon'un bahsettiği Alistair Cockburn'ün yazdığı makaleye daha yakından bakarsanız, durumun böyle olmadığını göreceksiniz. Aslında bundan çok daha ilginç.
Port, uygulamayla belirli bir etkileşim türü (dolayısıyla "protokol" kelimesi) için tasarlanmış, teknolojiden bağımsız bir uygulama programlama arabirimidir (API). Bu protokolü nasıl tanımlayacağınız tamamen size bağlıdır ve bu yaklaşımı heyecan verici kılan da budur. İşte sahip olabileceğiniz farklı portlara birkaç örnek:
- Bir veritabanına erişmek için uygulamanız tarafından kullanılan bir port
- Uygulamanız tarafından e-posta veya kısa mesaj gibi mesajlar göndermek için kullanılan bir port
- İnsan kullanıcılar tarafından uygulamanıza erişmek için kullanılan bir port
- Uygulamanıza erişmek için diğer sistemler tarafından kullanılan bir port
- Uygulamanıza erişmek için belirli bir kullanıcı grubu tarafından kullanılan bir port
- Belirli bir kullanım durumunu ortaya çıkaran bir port
- İstemcileri sorgulamak için tasarlanmış bir port
- Müşterilere abone olmak için tasarlanmış bir port
- Senkronize iletişim için tasarlanmış bir port
- Eşzamansız iletişim için tasarlanmış bir port
- Belirli bir cihaz türü için tasarlanmış bir port
Bu liste hiçbir şekilde kapsamlı değildir ve eminim daha birçok örneği kendiniz de bulabilirsiniz. Bu türleri de birleştirebilirsiniz. Örneğin, yöneticilerin senkronize olmayan iletişim kullanan bir istemci kullanarak kullanıcıları yönetmesine olanak tanıyan bir porta sahip olabilirsiniz. Diğer bağlantı noktalarını veya domain modelini etkilemeden sisteme istediğiniz veya ihtiyaç duyduğunuz kadar port ekleyebilirsiniz.
Altıgen mimari şemasına tekrar bakalım:
İç altıgenin her bir tarafı bir portu temsil eder. Bu mimarinin genellikle bu şekilde tasvir edilmesinin nedeni budur: Farklı portlar için kullanabileceğiniz kutudan çıkar çıkmaz altı tarafa ve ihtiyacınız olduğu kadar çok sayıda adaptör çekmeniz için bolca alana sahip olursunuz. Ama adaptör nedir?
Adaptör nedir?
Bağlantı noktalarının (portların) teknolojiden bağımsız olduğundan bahsetmiştim. Yine de, bazı teknolojiler aracılığıyla sistemle etkileşime girersiniz - bir web tarayıcısı, bir mobil cihaz, özel bir donanım cihazı, bir masaüstü istemcisi vb. Adaptörlerin devreye girdiği yer burasıdır.
Bir adaptör, belirli bir teknolojiyi kullanarak belirli bir port üzerinden etkileşime izin verir. Örneğin:
Bir REST adaptörü, REST istemcilerinin bazı portlar aracılığıyla sistemle etkileşime girmesine izin verir
Bir RabbitMQ adpter, RabbitMQ istemcilerinin bazı portlar üzerinden sistemle etkileşime girmesine izin verir.
Bir SQL adaptörü, sistemin bazı portlar üzerinden bir veritabanı ile etkileşime girmesine izin verir
Bir Vaadin adaptörü, insan kullanıcıların bazı portlar aracılığıyla sistemle etkileşime girmesine olanak tanır
Tek bir port için birden çok adaptöre veya birden çok port için tek bir adaptöre sahip olabilirsiniz. Diğer adaptörleri, portları veya domain modelini etkilemeden sisteme istediğiniz veya ihtiyaç duyduğunuz kadar adaptör ekleyebilirsiniz.
Koddaki Portlar ve Adaptörler
Şimdiye kadar, kavramsal düzeyde bir portun ve adaptörün ne olduğu hakkında bir fikriniz olmalı. Peki bu kavramları koda nasıl dönüştürürsünüz? Bir bakalım!
Portlar çoğu durumda kendilerini kodunuzda arayüzler olarak somutlaştırır. Dış sistemin uygulamanıza erişmesine izin veren portlar için bu arabirimler, application servisi arabirimlerinizdir:
Arayüzünüzün uygulanması, application servis katmanınızın içinde bulunur ve adaptörler, servisi yalnızca arayüzü aracılığıyla kullanır. Bu, adaptörün applicaiton katmanınızı kullanan başka bir istemci olduğu klasik katmanlı mimariye çok uygundur. Temel fark, port kavramının daha iyi uygulama arabirimleri tasarlamanıza yardımcı olmasıdır, çünkü arabirimlerinizin istemcilerinin ne olacağını gerçekten düşünmeniz gerekir ve farklı istemcilerin tek boyutta uyum sağlamak yerine farklı arabirimlere ihtiyaç duyabileceğini kabul etmeniz gerekir.
Uygulamanızın bir adaptör aracılığıyla harici bir sisteme erişmesine izin veren bir porta baktığımızda işler daha ilginç hale geliyor:
Bu durumda, arayüzü uygulayan adaptördür. Application servisi daha sonra bu arabirim aracılığıyla adaptörle etkileşime girer. Arabirimin kendisi uygulama hizmet katmanınızda (factory arabirimi gibi) veya domain modelinizde (repository arabirimi gibi) bulunur. Arayüz bir üst katmanda ("uygulama katmanı" veya "domain katmanı") bildirileceği, ancak daha düşük bir katmanda ("altyapı katmanı") uygulanacağı için bu yaklaşıma geleneksel katmanlı mimaride izin verilmezdi.
Lütfen bu iki yaklaşımda da bağımlılık oklarının arayüzü işaret ettiğine dikkat edin. Uygulama her zaman adaptörden ayrılmış olarak kalır ve adaptör her zaman uygulamanın gerçekleştirilmesinden ayrı kalır.
Bunu daha da somut hale getirmek için bazı kod örneklerine bakalım.
Örnek 1: REST API
İlk örnekte Java uygulamamız için bir REST API oluşturacağız:
Port, REST aracılığıyla açığa çıkmaya uygun bazı application servisidir. REST controller'ı adaptör görevi görür. Doğal olarak, POJO'lar (Düz Eski Java Nesneleri) ve XML / JSON arasında hem sunucu uygulaması hem de eşleştirme sağlayan Spring veya JAX-RS gibi bir frameork kullanıyoruz. Sadece aşağıdakileri yapacak olan REST controller'ını uygulamalıyız:
- Input olarak ham XML / JSON veya serileştirilmemiş POJO'ları alın,
- Application servislerini çağırın,
- Frameork tarafından serileştirilecek ham XML / JSON veya POJO olarak bir yanıt oluşturun ve
- Response'u client'e iletin.
İstemciler, bir tarayıcıda çalışan istemci tarafı web uygulamaları veya kendi sunucularında çalışan diğer sistemler olup olmadıklarına bakılmaksızın, bu belirli altıgen sistemin bir parçası değildir. Sistem ayrıca, port ve adaptörlerin desteklediği protokole ve teknolojiye uydukları sürece istemcilerin kim olduğuna da aldırmak zorunda değildir.
Örnek 2: Sunucu Tarafı Vaadin Kullanıcı Arayüzü
İkinci örnekte, farklı bir adaptör türüne, yani sunucu tarafı Vaadin UI'ye bakacağız:
Port, bir web kullanıcı arayüzü aracılığıyla gösterilmeye uygun bazı application servisidir. Adaptör, gelen kullanıcı eylemlerini applicaiton servisi yöntemi çağrılarına ve çıktıyı tarayıcıda işlenebilen HTML'ye çeviren Vaadin UI'dir. Kullanıcı arayüzünü yalnızca başka bir adaptör olarak düşünmek, iş mantığını kullanıcı arayüzünün dışında tutmanın mükemmel bir yoludur.
Örnek 3: İlişkisel Veritabanı ile İletişim Kurma
Üçüncü örnekte, işleri tersine çevireceğiz ve sistemimizin harici bir sisteme, daha özel olarak ilişkisel bir veritabanını çağırmasını sağlayan bir adaptöre bakacağız:
Bu sefer, Spring Data kullandığımız için, port, domain modelinden bir repository arayüzüdür (Spring Data kullanmadıysak, port muhtemelen repository uygulamalarına, transaction yönetimine erişim sağlayan bir tür veritabanı ağ geçidi arayüzü olacaktır. ve bunun gibi).
Adaptör Spring Data JPA'dır, bu yüzden gerçekten kendimiz yazmamız gerekmez, sadece doğru şekilde kurmamız gerekir. Uygulama başladığında ara yüzü proxy kullanarak otomatik olarak uygulayacaktır. Spring konteyneri, proxy'yi onu kullanan applicaiton servisine inject etmeyle ilgilenir.
Örnek 4: REST Üzerinden Harici Bir Sistemle İletişim Kurma
Dördüncü ve son örnekte, sistemimizin REST üzerinden harici bir sisteme istek yapmasını sağlayan bir adaptöre bakacağız:
Application servisinin harici sisteme ulaşma ihtiyacı olduğu için bunun için kullanmak istediği bir arayüz ilan etmiştir. Bunu bir anti-corruption katmanının ilk bölümü olarak düşünebilirsiniz (ne olduğu konusunda tazelemeye ihtiyacınız varsa geri dönün ve stratejik DDD hakkındaki makaleyi okuyun).
Adaptör daha sonra bu arabirimi uygulayarak anti-corruption katmanının ikinci bölümünü oluşturur. Önceki örnekte olduğu gibi, bağdaştırıcı, Spring gibi bir tür bağımlılık enjeksiyonu kullanılarak uygulama hizmetine enjekte edilir. Daha sonra, harici sisteme çağrı yapmak için bazı dahili HTTP istemcilerini kullanır ve alınan yanıtları, entegrasyon arabiriminin belirlediği şekilde domain nesnelerine çevirir.
Çoklu Sınırlı Bağlamlar(Multiple Bounded Contexts)
Şimdiye kadar sadece tek bir sınırlı bağlama uygulandığında altıgen mimarinin nasıl göründüğüne baktık. Ancak birbirleriyle iletişim kurmanız gereken birden fazla sınırlı bağlamınız olduğunda ne olur?
Bağlamlar ayrı sistemlerde çalışıyorsa ve bir ağ üzerinden iletişim kuruyorsa, bunun gibi bir şey yapabilirsiniz: Yukarı akış sistemi için bir REST sunucu adaptörü ve aşağı akış sistemi için bir REST istemci adaptörü oluşturun:
Farklı bağlamlar arasındaki eşleştirme, aşağı akış sisteminin adaptöründe gerçekleşecektir.
Bağlamlar tek bir monolitik sistem içinde modüller olarak çalışıyorsa, yine de benzer bir mimari kullanabilirsiniz, ancak yalnızca tek bir adaptöre ihtiyacınız vardır:
Sonraki: Domaine Dayalı Tasarım ve Spring Boot
Bu dizinin bir sonraki ve son makalesinde, domaine dayalı tasarımı ve altıgen mimariyi kullanarak uygulamalar oluşturmak için Spring Boot'u nasıl kullanacağımızı öğreneceğiz.
Çeviri için izin veren Petter Holmström'e teşekkürler.
Bonus :
Barış Velioğlu
Domain Driven Design Kimdir?
Türk Ninja IT Dünyası'ndan haberler, röportajlar, makaleler, eğitimler ve video içerikleri sunar.
