Buradaki yazımda teknik borcun ne olduğunu, nasıl oluştuğunu ve nasıl ödenebileceği konusuna değinmiştim. Teknik borç kodu doğrudan ilgilendiren ve projenin sürdürülebilirliğini etkileyen bir durumdur. Bu yazımda teknik borç kadar dikkat görmeyen, lakin yazılım projesinin kaderini teknik borçlanmaya nazaran daha belirleyici olan alan borçlanmasından bahsetmek istiyorum.

Her yazılım sisteminin hitap ettiği bir alan (domain) vardır. Bu alanda yer alan iş süreçleri yazılım sisteminin şekillendirilmesinde yön verirler. Yazılım sisteminin merkezinde alan modeli (domain model) yer alır. Alan modeline dayalı olmayan ya da alandaki iş süreçlerinden doğan gereksinimleri tatmin edemeyen yazılım sistemi oluşturulma hedefine ulaşamamıştır ve alan kullanıcıları tarafından kullanılabilecek yapıda değildir.

Bir önceki paragrafta yer alan teknik terimleri bir örnek üzerinde inceleyelim. İnternet üzerinden sipariş yapmak için kullanılan bir sistemin hitap ettiği alan internet tabanlı alışveriştir (online shopping). Yazılım sisteminin merkezinde yer alan alan modelindeki öğeler (entity) müşteri, sipariş, ürün, adres, ödeme şekli, fatura, alışveriş sepeti gibi yapılardır. Alan kullanıcıları sipariş veren müşteriler ya da gelen siparişleri gözden geçiren çalışanlardır. Örneğin bir müşterinin sipariş verebilmesi için önce seçtiği ürün ya da ürünleri alışveriş sepetine eklemesi gerekmektedir. Siparişin temelini bu örnekte alışveriş sepeti oluşturmaktadır. Bunun yanı sıra müşterinin adres ve ödeme bilgileri sipariş esnasında girmesi gerekmektedir. Sistem çalışanları yönetim paneli aracılığı ile gelen siparişler hakkında bilgi edilebilirler. Burada iş süreçleri devreye girmektedir. Mevcut bir siparişin nasıl yönetildiğini bir iş süreci belirler. Bu iş süreci siparişin yönetimi ile ilgili tüm detayları ihtiva eder. Yazılım sistemi bu detayların koda dökülmüş halidir. İş süreçlerinden gereksinimler doğar ve yazılım sistemi bu gereksinimleri tatmin etme görevini üstlenir.

Oluşturulan yazılım sistemi sadece gerçeği modellemeye çalışan bir araçtır. Bu model gerçeğe ne kadar yakın ise, o oranda yazılım sisteminin kullanımı kolaylaşır ve teşvik edilir. Oluşturulan modelin gerçek ile örtüşür hale gelebilmesi için yazılım ekibinin yazılım sistem sahibi yani müşterileri ile sıkı diyalog halinde olmaları gerekmektedir. Bu her zaman geçerli olmamakla birlikte, sadece müşteri nasıl bir sistem sahibi olmak istediğini bilebilir. Burada yazılım ekibinin öncelikli görevi müşteri gereksinimlerini tespit etmek, iş süreçlerini anlamak ve buradan yola çıkarak bir alan modeli oluşturmaktır. Alan modeli ve iş süreçlerinin implementasyonu gerçeğe ne kadar yakın olurlarsa, projenin başarılı olması o oranda artacaktır. Bunun eksikliği müşterinin kullanmayı reddettiği ve gereksinimlerini tatmin etmeyen bir yazılım ürünü olacaktır.

Bu açıklamalar ışığında alan borçlanmasının ne olduğunu ve nasıl oluştuğunu inceleyelim. Alan borçlanmaları oluşturulan alan modeli ve iş süreçleri implementasyonlarının mevcut ve gelecekteki yeni gereksinimleri tatmin etmek üzere yapılan çalışmaların zora girmesi ile kendilerini gösterirler. Alan borçlanmalarının oluşma şekillerini şu şekilde sıralamak mümkündür:

• Yazılım ekibi müşteriyi ve gereksinimlerini yeterince anlamadığı için yazılımı yanlış bir model üzerine inşaa eder. Model gerçekleri yansıtmadığı için yazılım ekibi müşteri gereksinimlerini implemente etmekte zorlanır.
• Mevcut alan modeli genel tutulduğundan ve alt alanlarda (subdomain) ortak kullanıldığından çok sıklıkla değişikliğe uğrar ve alt alanların ihtiyaçlarını tatmin edemez hale gelir. Bu şekilde yapılmak istenen değişiklikler zorlaşır, çünkü model tüm alt alanları destekleyecek esnekliğe sahip değildir.
• Müşterinin gerekli bilgileri sağlamaması neticesinde yazılım ekibi doğru düşündüğü şekilde modeli oluşturur. Yeni gelen bilgiler doğrultunda modelin yetersiz olduğu tespit edilir. Bu proje bünyesinde geniş çaplı bir yeniden yapılandırma (refactoring) gereksinimi doğurabilir. Bu çapta bir yeniden yapılandırma için gerekli zaman olmadığı için mevcut alan modeli uygulamanın çeşitli yerlerinde oluşturulan yerel alan modellerine dönüştürülerek (mapping) tekrar kullanılır.
• Programcılar genel alan modelinde yer alan öğelerden bazılarını yerel implementasyonlarında tekrar (reuse) kullanırlar. Lakin kullanım bağlamı (context) değiştiği için kullanılan ögeler yetersiz kalabilir. Aynı zamanda genel alan modelinde yapılan değişiklikler ögelerin başka bağlamda kullanıcılarını kırılgan hale getirebilir.

Kimi zaman bilgi yetersizliği, kimi zaman yanlış anlaşılmalar ve kimi zaman zaman yetersizliği alan borçlanmasına sebep verebilmektedir. Teknik borçlanmalara kıyasla alan borçlanmaları bir projenin tamamen durma noktasına gelmesine sebep olabilmektedirler. Bunun önüne geçmek için yazılım ekibinin alan eksperleri ile sıkı bir diyalog içinde olmaları ve ortak bir alan dili oluşturmaları gerekmektedir. Bu ortak dil programcıların ihtiyaç duyulan alan modelini oluşturmalarını ve gerekli şekilde kullanımını kolaylaştırıcı nitelikte olacaktır.

Alan borçlanmasını önlemek için müşteri ve yazılım ekibi arasında sıkı bir diyaloğun ve ortak bir alan dilinin oluşturulması gerektiğinden bahsettim. Peki teknik olarak alan borçlanmasını önlemek için kullanılabilecek yöntemler var mıdır? Teknik borcun ödenmesinde olduğu gibi alan borçlanmaları da kod yeniden yapılandırılarak ödenebilirler. Bu çok masrafla bir uğraşı haline dönüşebilir. Durumun bu hale gelmesini önlemek için projenin başlangıç safhalarında gerekli önlemlerin alınması gerekmektedir. Bu yöntemler nelerdir?

Domain Driven Design (DDD) olarak bilinen yöntemde sınırlı bağlam (bounded context) olarak bilinen bir metot mevcuttur. Bu metot ile sınırlı geçerlilik alanı bulunan alan modelleri oluşturulur. Modeller birbirlerinden bağımsızdır ve geçerli oldukları alanlar belirlidir. Modellerin ya da sahip oldukları parçaların tanımlandıkarı bağlam haricinde kullanılmları yasaktır. Bu şekilde bir model bir sorumluluk prensibi uygulanmış olur. Tek sorumluluk prensibinden de bildiğimiz gibi bir yazılım öğesinin birden fazla sorumluluk taşıması onun kırılganlığını artırır. Sınırlı bağlam bunu önleyici bir yöntemdir ve oluşturulan alan modellerinin tek bir sorumluluk ile tanımlanmalarını mümkün kılar.

Teknik ve alan borçlarıyla başetmenin en verimli yöntemi oluşmalarını engellemektir. Bunun için kullanılabilecek yöntemlerin başında çevik süreçler gelir. Örneğin test güdümlü yazılım yeniden yapılandırma süreci kolaylaştırır. Hızlı bir şekilde yapılabilen yeniden yapılandırma kodu rehin alan her türlü borcun ödenmesini kolaylaştırır. Ama kanımca çevik süreçlerde her türlü borçlanmayı engelleme potansiyeline sahip başka bir yöntem daha mevcuttur. Bu yöntem aracılığı ile belli zaman dilimlerinde yeni sürümler oluşturularak, gelinen durum müşteri ile paylaşılır. Müşteriden alınan geribildirim aracılığı ile model hataları kısa zamanda farkedilir ve gerekli düzeltmeler gerçekleştirilir. Burada çevik süreçler bünyesinde yer alan yazılım metotlarının tamemen geribildirim döngüleri üzerine kurulu olduğunu söylemek doğru olacaktır. Test yazımı, sürekli entegrasyon, eşli programlama, sürekli yeni sürüm oluşturmak her daim geribildirim alınmasını ve gerekli rota değişikliği yapılamasını mümkün kılar. Bu bağlamda teknik ve alan borçlarının aslında yetersiz ya da mevcut olmayan geribildirimi döngülerinden kaynaklandığını söylemek yanlış olmayacaktır.

Teknik borç konusunun yazılımcılar arasında sıkça dile gelen bir konu olduğuna şahit olmaktayım. Lakin alan borçlanması o kadar sıkça dile gelen bir konu değildir. Her yazılım projesinde alan borçlanmasına şahit olmak mümkündür. Kod kalitesi ne kadar iyi olursa, olsun yanlış bir alan modeli yeni değişikliklerin yapılmasını zorlaştıracaktır. Bu duruma gelmemek için öncelikle alan borçlanmasını da ciddi bir proje riski olarak görülmesi ve projenin başlangıcından itibaren bu konuya gerekli önemin verilmesi gerekmektedir.

EOF (End Of Fun)
Özcan Acar