Domain Driven Desig Temelleri - Domain Modelling

Giriş

Context Mapping’e Giriş

Kuruluşunuzun birden fazla sınırlı bağlamı varsa ve ideal olarak bunlar ayrıysa, farklı ekipler birbirleriyle konuşurken kafa karışıklığı olabilir. Yine, DDD, özellikle ürettiğimiz kodla ilgili herhangi bir şey üzerinde olduğu kadar en az etkili iletişime odaklanır. Evans, bağlamları arasındaki sınırların nerede olduğunu tüm ekiplere görselleştirmek ve göstermek için bağlam haritalarının kullanılmasını önerir. "Veritabanınızı paylaştığınız ve yüzlerce farklı süreç tarafından güncellenen bir şirkette iseniz, bahsettiğimiz türden modeller oluşturmak ve sonra bu modellerle ilginç bir şey yapan yazılımlar yazmak çok zor. " Domain Modelin Elemanları

Domain yazilim kalbidir. (The domain is the heart of business software. ) Bu yüzden domain modellenmesi de DDD nin başlangıcında yapmamiz gereken önemli bir istir. Fakat DDD de kullanilan bazi kavramlar kafanızı karıştırabilir. Mesela Entity kavrami database orm leri için başka bir anlama gelirken, DDD de ise cok baska bir anlamda kullanilir. Ayni sekilde Context de database ORM lerinde mesela Entity Framework de cok farkli bir amac icin kullanirken DDD de ise cok degisik bir anlamda dir.

Burada önemli olan husus yapacağımız yazılımın nasil calisacagina dönük teknik ayrıntılardan ziyade Domaine odaklanmak olmalidir. Bir domain modellerken, sadece nesnelerin durumunu değiştirmeye değil, o domain’in davranışlarına da odaklanmamız gerekir. Yeni sistemin nasil davrandigina odaklanmamız gerektiğinden bahsediyoruz.

Event’leri Tanımlamak Behaviour İleri Anlamayı Sağlar Yazmaya calistigimiz uygulamanin dahil oldugu sistemi iyi anlayabilmek için Event’lere bakmak cok yararli olur. Böylece sistemin önemli davranislarini (Behaviour) anlariz ve domain’imizi daha iyi modelleyebiliriz. Bu amaçla Domain expert ler ve diger paydaslar ile Event Storming calismalari yapmak cok faydali olur. Bu calismayi domain expertler ile yaparken her olayi dili geçmiş zamanda yazarak bir tabloda toplayabiliriz. Örneğin bir randevu alindi, bir müsteri ofis ile iletisime gecti ya da bir hasta tartildi gibi.

Anemik ve Zengin Alan Modellerini Karşılaştırma

Zengin alan modelleri, alanınızın davranışlarını ve iş mantığını temsil edecektir.

Entity Leri Anlamak

DDD de sistemin davranislari ön plandadir ama bize kod yazmak icin nesneler gerekmektedir. DDD de iki tür nesne vardir.

1- Defined by an İdentity (Bir kimlik ile tanimlanan) 2- Defined by its Values (Sahip oldugu degerler ile tanimlanan)

Birinci tür nesnelere Entity denir. Bir entity, Bir kimlik anahtari (ID) ile izleyebileceğimiz, bulabildiğimiz, geri alabileceğimiz ve saklayabileceğimiz nesnedir. Özellikleri değişebilir, bu nedenle özelliklerini nesneyi tanımlamak için kullanamayız.

Terms

Anemic Domain Model Model with classes focused on state management. Good for CRUD.

Rich Domain Model Model with logic focused on behavior, not just state. Preferred DDD.

Entity A mutable class with an identity (not tried to its property values) used for tracking and persistence. Message Queues are one way to share data across bounded contexts. Model de ki Value Objeleri ve Servisleri Anlamak DDD de iki tür nesne oldugundan bahsetmiştik. Birincisi kimliğine (identity) göre tanımlanan, ikincisi ise değerleriyle tanımlanan. Bu ikinci nesnelere Value Objects deniyor ve en az ilki kadar önemliler. Value Nesnelerinin bazi cok temel özellikleri vardir. Bu nesnelere Domain de tanımlı olan bazi seyleri ölçmek, saymak yada tanimlamak için kullanılan nesnelerdir. Özel bir anahtar ile (key) kimliğini tanimlamak yerine, bu nesnelerin kimligi sahip oldugu degerlerin bilesimine dayanir.
Bu nesneler değişmezdir (Immutable). Bu nesnelerin özelliklerini bir kere yarattıktan sonra degistiremiyor olmanız gerekmektedir. Bunun yerine nesnenin başka bir instance in yeni degerler (value) ile yaratmamız gerekmektedir. Iki Value nesneninin esitliginii kontrol etmek istedigimizde tüm değerlerini karsilastirma miz gerekmektedir. Value nesnelerin Eventleri yada Davranislari olabilir fakat asla yan etkileri olmamalıdır (side effects). Value nesnelerinde ki metodlar asla nesnenin ya da sistemin state ini degistirilmelidir.

String value nesnesidir ve immutabledir. Money is a Great Value Object. Value nesnelerini mümkün oldugu kadar cok kullanmamiz salik veriliyor. Modellerken ilk düşünce olarak acaba bu Value Nesnesi olur mu? diye kendimize sormamiz daha verimli sonuçlar almamizi saglar. Bunun nedeni, Entity lerden ziyade Value Nesnelerine odaklanmak daha önemlidir. The state of a value object should not be changed once it has been created. Yaratıldıktan sonra Value nesnesini durumunu (state) kesinlikle degistiremiyor olmanız gerekmektedir. Domain Servisleri Some operations make more sense in a domain service. Basi operasyonlarin domain servisin icinde olmasi daha mantiklidir. Bunlar Entityler ve Value nesnelerini yönetirler. Temel karakteristikleri: İyi bir domain service entity nin yada value nesnesinin dogal bir parcasi degildir. Diğer domain modeli öğeleri açısından bir interface tanımlanmış mı. Stateless, fakat side efekti olabilir. Uygulamanin kalbinde yaşarlar. Örnek olarak: UI ve App icin: Message Sending, Message Processing, XML Parsing, UI Services. Domain: Orchestration workflow, Transfer between Accounts, Process Order. Infrastructure: Send Email, Log to File or service. Domain servisleri genellikle sadece eger bir entity ya da value nesnesi ile yapamadigimiz durumlarda kullanilmalidir.

Aggregate (Kümeleme)

Eger domain modelimiz cok karmasiksa kümeler ile bu karmasikligi giderebiliriz. Fakat kümeleme bir opsiyon diye her zaman karmasik durumlarda kümeleme yapmamiz gerekmez. Kümeleme yapmak icin kümeleme yaparsak modelimize ekstra karmasiklik ekleriz.

Bir diğeri dikkat etmemiz gereken hususta, kümelenmis entity’ler yalnızca başka bir kümenin root entitiy’sini referans gösterebilmelidirler. Ancak FK değerlerini her zaman başka bir küme içindeki entityi referans olarak kullanabilirsiniz. Bu sekilde kullanmakta hiçbir sakınca yoktur ve kalıcılığını diğer kümelere kademeli olarak aktarması için bu kümeyi kaydetmeye gittiğinizde ihtiyaç duymazsınız.

Alt öğeleri bir araya getirmek için çok sayıda FK kullanmanız gerektiğini fark ederseniz, etki alanı modelinizde küme (aggregate) tasarımınızı yeniden gözden geçirmeniz gerekebilir.

Gene diger önemli bir hususta, bir kümeye sahip olmaktan korkmayın, başka bir deyişle, içinde yalnızca bir nesne bulunan bir kümeye sahip olmaktan.

Ve son olarak, art arda silme kuralını unutmayın. O kümeyi sildigimizde o kümeye ait tümnesnelerinde silinip silnmeyecegine bakmamiz gerekmektedir. Gerekmiyorsa muhtemelne kümemiz icin yanlis bir yapi secmisizdir. Aggreagete (küme)

Aggregates are not always the answer. Aggregates can connect only by the root. Don’t overlook using FKs for non-root entities. Too many FKs to non-root entities may suggest a problem. Aggregates of one are acceptable Rule of Cascading Deletes.

Aggregate Rules

Reference other aggregates by id Changes are commited & rolled back as a whole Changes to an aggregate are done via the root. Aggregate modeling steps Define each of the entities is an aggregate Merge aggregates to enforce invariants Merge aggregates that cannot tolerate eventual consistency

Good questions to ask Does the entity make sense without the other? NO it might be local entity. If the entity doesn’t make any sense without the other entity then ikt might be a local entity and not a aggregate root. Will it need to be looked up? Will it be referenced by other aggregates? If yes probably aggregate root