Kalıcı veri model­le­mesi

Uzun ömürlü bir sisteme dikkatle bakıldığında, bir kalıcılık sıralaması göze çarpar. En dıştaki katman — arayüz — en sık değişir. Onun altında, yıllar içinde güncellenen ya da değiştirilen framework yer alır. Daha derinde, zahmetle değiştirilebilen veritabanı bulunur. En altta, hepsinden kalıcı olan ise verinin kendi biçimidir: hangi şeylerin var olduğu, birbirleriyle nasıl ilişkilendiği, birbirlerinden neyle ayrıldığı. Bu biçim üzerindeki her şeyi aşar — ve bu yüzden uzun ömürlülük üzerinde başka herhangi bir seçimden daha belirleyicidir.

Bu doküman veri modelini olduğu gibi ele alır: bir sistemin üzerinde durduğu temel olarak. Bilinçli olarak veritabanından ve framework'ten bağımsız tutulmuştur, çünkü konusu verinin yapısıdır, onu saklayan teknoloji değil. Bu koleksiyondaki diğer metinler veri modeline sürekli olarak asıl belirleyici katman diye atıfta bulunur; bu metin ise bunu ayrıntılı biçimde ele alan metindir. Rakam verilmemektedir.

1. Veri modeli neden her şeyi aşar

Bir veri modeli çevresindeki teknolojiyi aşar, çünkü teknolojiyi değil, sistemin yönettiği gerçekliği yansıtır. Bir müşteri, bir sipariş, bir sözleşme, bir iş süreci — bu şeyler ve aralarındaki ilişkiler, onları işlemek için kullanılan framework'lerden çok daha yavaş değişir. Arayüzü yeniden inşa edebilir, framework'ü değiştirebilir, hatta veritabanını taşıyabilirsiniz; bunların hiçbiri bir müşterinin ne olduğunu ve bir siparişle nasıl bir ilişkide olduğunu değiştirmez. Modelin kalıcılığı tam da buradadır: Teknolojiye karşı kayıtsızdır.

Özen sıralaması da buradan çıkar. Veri modeli en uzun yaşadığı ve üzerindeki her şeyi taşıdığı için, tasarımda en fazla dikkati hak eder — framework seçiminden de, veritabanı seçiminden de, arayüz tasarımından da fazla. Arayüzdeki bir hata bir yeniden yapılanmaya mal olur; veri modelindeki bir hata ise üzerinde duran her şeyin yeniden yapılanmasına. Özen sırasını tersine çevirip uzun uzun framework tartışırken modelin bir kenarda kendiliğinden oluşmasına izin veren, güçlerini yanlış dağıtmış demektir.

Şema: Katman ne kadar derindeyse o kadar uzun yaşar. En alttaki veri modeli arayüzü, framework'ü ve veritabanını aşar — ve hepsini taşır.

Avantajlar ve sınırlamalar. Veri modeline özen göstermek, kullanıcıların doğrudan görmediği bir alana daha fazla zaman ayırmayı gerektirir. Karşılığında sistemin uzun vadeli temeli güçlenir.

Maliyet. İyi düşünülmüş bir model, aceleyle çiziktirilmiş bir tablo yapısından daha yavaş ortaya çıkar ve atlanamayacak bir deneyim gerektirir.

Ne zaman farklı karar veririz. Verileri hiçbir zaman uzun ömürlü bir sisteme aktarılmayacak, kullanılıp atılacak bir prototipte tam özen abartıdır — orada hız önemlidir ve model kaba kalabilir.

2. Arayüzü değil, alanı modellemek

En yaygın ve en ağır sonuçlu hata, veriyi o anda ekranda ya da arayüzde ihtiyaç duyulan şeye göre biçimlendirmektir. Bir formun belirli alanları vardır, siz de tam bu alanlara sahip bir tablo oluşturursunuz; bir görünüm belirli bir derlemeyi gösterir, siz de veriyi bu derlemeyle saklarsınız. Bu caziptir, çünkü kısa vadede en az işi çıkarır — uzun vadede ise pahalıdır, çünkü arayüzler değişir ve model artık uymaz.

Veri modeli arayüzü değil, alanı (domain) yansıtmalıdır: şeyleri, bugün nasıl gösterildiklerinden ya da sorgulandıklarından bağımsız olarak, gerçekte oldukları ve birbirleriyle ilişkilendikleri biçimde. Alanı doğru yakalayan bir model arayüzün her yeniden tasarımını atlatır, çünkü görünüm değişirken alan sabit kalır. Arayüzü yansıtan bir model ise arayüzdeki her değişiklikle birlikte yer değiştirmek zorundadır — ve ilk büyük yeniden yapılanmada bir engele dönüşür. Soru “ekran hangi alanları gösteriyor?” değil, “bu şey gerçekte nedir ve neyle ilişkilidir?” sorusudur.

Avantajlar ve sınırlamalar. Form alanlarını kopyalamak yerine iş alanını modellemek, başlangıçta daha fazla analiz gerektirir. Karşılığında veri yapısı gerçek iş ilişkilerini daha doğru yansıtır.

Maliyet. Alana yakın bir model, bazen verinin biçimi ile görüntülemenin biçimi arasında, aksi hâlde gerekmeyecek bir dönüşüm gerektirir.

Ne zaman farklı karar veririz. Bir görüntüleme ile alanın gerçekten örtüştüğü ve kalıcı olarak öyle kalacağı yerlerde ayrım aşırı mühendisliktir; o zaman zaten ikisi birden olan şeyi doğrudan modellersiniz.

3. Değişim için modellemek

On yıl taşıması beklenen bir veri modelinin değiştirilebilir olması gerekir, çünkü alan zamanla büyür ve kayar. Her uzun ömürlü yapıda olduğu gibi, ustalık geleceği tahmin etmekte değil, modeli değişimin ucuz kalacağı şekilde kurmaktadır. Bu her şeyden önce şu demektir: eklemeli (additive) büyüyebilmek. Yeni bir özellik, mevcut olanın anlamını kaydırmadan yeni bir alan ya da yeni, bağlantılı bir şey olarak eklenir. Ancak mevcut olanı yeniden yapılandırarak büyüyebilen bir model, her değişiklikle daha riskli hâle gelir.

Buna, bildiğinizden fazlasını sabitlememek de dahildir. Erken aşamada akla gelebilecek her özelliği katı bir yapıya sıkıştıran bir model, düşünülmemiş o tek özellik karşısında kırılgandır. Modelde ölçülülük — yalnızca alanın gerçekten gerektirdiğini sabitlemek ve henüz netleşmemiş olana alan bırakmak — mimarideki geri alınabilirlikle aynı tutumdur: geri alınabilir olanı ucuz tutmak, geri alınamaz olanı geç ve bilinçli olarak sabitlemek. Çünkü çalışan bir sistemin veri modelinde yapılan değişiklik, akla gelebilecek en geri alınamaz müdahalelerden biridir — mevcut her kaydı etkiler.

Avantajlar ve sınırlamalar. Genişletilebilir veri modeli, yalnızca bugünkü duruma göre daha genel kalabilir. Bu yaklaşım, yeni gereksinimlerde mevcut veriyi dönüştürme ihtiyacını azaltabilir.

Maliyet. Değiştirilebilir bir model, eklemeli büyümenin kontrolsüz bir çoğalmaya dönüşmemesi için her genişletmede disiplin ve yapıyı ancak netleştiğinde sabitleme isteği gerektirir.

Ne zaman farklı karar veririz. Bir yapının yasa ya da değişmez bir dış sözleşme tarafından belirlendiği yerde onu sabitler ve ayrıntılı biçimde sabitlersiniz; değişmez bir şeye karşı açıklık israf olurdu.

4. Kimlik ve ilişkiler

Veri modelindeki iki karar diğer hepsinden daha kalıcıdır: Bir şeyi neyin benzersiz kıldığı ve şeylerin birbirleriyle nasıl ilişkilendiği. Kimlik — bir kaydı tam olarak o kayıt yapan ve diğer hepsinden ayıran şey — her ilişkinin, her referansın, her birleştirmenin dayandığı temeldir. Kötü seçilmiş bir kimlik — değişebilen, gerçekten benzersiz olmayan, iş anlamı taşıyan bir şeyi teknik bir şeyle karıştıran — tüm modeli zehirler, çünkü her şey onun üzerine kurulur. Kimlik, geri alınması en zor olan karardır.

Şema: Kimlik her şeyi ayırt edilebilir kılar; ilişkiler alanın nasıl işlediğini söyler. İkisi de en uzun süre dayanır ve değiştirilmesi en pahalı olanlardır.

İlişkiler ikinci kalıcı katmandır: hangi şeylerin hangilerine ait olduğu, birinin birçoğuyla mı yoksa birçoğunun birçoğuyla mı ilişkili olduğu, bir bağlantının zorunlu mu yoksa isteğe bağlı mı olduğu. Bu yapı, modelin alanın nasıl işlediğine dair asıl söylediğini oluşturur — ve onu değiştirmek, yalnızca yeni kod yazmak değil, neredeyse her zaman mevcut veriyi dönüştürmek demektir. Bu nedenle kimlik ve ilişkiler tüm tasarımdaki en büyük özeni hak eder: En uzun dayanan ve düzeltilmesi en pahalı olan onlardır. Bunları doğru belirleyen, modeli özünde doğru kurmuştur; ıskalayan ise hatayı tüm ömrü boyunca taşır.

Avantajlar ve sınırlamalar. Kimlikleri ve ilişkileri doğru seçmek, tasarımda dikkatli değerlendirme gerektirir. Bunlar veri modelinin en uzun süre korunan parçalarındandır.

Maliyet. Bu özen, sabitlemeden önce alanı gerçekten anlamayı gerektirir — kısaltıldığında sonradan pahalı biçimde telafi edilmesi gereken bir iş.

Ne zaman farklı karar veririz. Bir şeyin açıkça ve istikrarlı biçimde tanımlandığı ve ilişkilerinin net olduğu yerde hızlı karar verirsiniz; tam özen, kimliğin ya da ilişkinin ilk bakışta net olmadığı durumlar içindir.

5. Normalizasyon ve pragmatik ölçüsü

Veri modellemesinin klasik disiplini normalizasyondur: Her olguyu tam bir kez, yetkili tek bir yerde saklamak; böylece çelişkili kopyalar oluşamaz. Bu, “bir bilgi birimi, tek bir temsil” fikrinin aynısıdır — veriye uygulanmış hâli. Normalize edilmiş bir model doğruya sadıktır: Kendisiyle çelişemez, çünkü her olgunun yalnızca bir yeri vardır. Yıllar boyunca doğruluk açısından bu yüksek bir değerdir, çünkü çelişkili veri, akla gelebilecek en inatçı hata kaynaklarından biridir.

Her ilke gibi bunun da bir ölçüsü vardır. Katı normalizasyon sorguları zahmetli ve pahalı hâle getirebilir; bilinçli, kontrollü bir yedekliliğin (redundancy) daha iyi seçim olduğu durumlar vardır — yeter ki bunu üstlendiğinizi bilin ve kopyaların tutarlı kalmasını sağlayın. Ustalık dogmatik biçimde normalize etmekte ya da dogmatik biçimde basitleştirmekte değil, şu soruyu sormaktadır: Bu olgu burada yetkili mi, yoksa yalnızca bir kopya mı? Kopyaysa: Onu kim tutarlı tutuyor? Bu soruları bilinçli olarak yanıtlayan bir model kalıcıdır; fark edilmeden yedeklilik biriktiren bir model ise zamanla çelişkilere doğru kayar.

Avantajlar ve sınırlamalar. Normalizasyon veri tutarlılığını destekler, ancak sorguları karmaşıklaştırabilir. Bilinçli veri tekrarı sorguları sadeleştirebilir; karşılığında kopyaların tutarlı tutulması gerekir.

Maliyet. Bilinçli yolların ikisi de kararın verilmesini ve belgelenmesini gerektirir; pahalı olan, yedekliliğin fark edilmeden biriktiği üçüncü, bilinçsiz varyanttır.

Ne zaman farklı karar veririz. Doğruluğun her şeyin önünde geldiği yerde — para, hukuk, stok — katı biçimde normalize edersiniz; ölçülmüş bir okuma yükünün birleştirmeyi fazla pahalı kıldığı yerde kontrollü yedekliliği üstlenir ve onu kimin tutarlı tuttuğunu açıkça belirlersiniz.

6. Yanlış bir modelin maliyeti

Yanlış bir veri modeli, bir sistemin taşıyabileceği en pahalı hatadır, çünkü her şey onun üzerine kurulur. Arayüzdeki bir hata yereldir; iş mantığındaki bir hata sınırlıdır; veri modelindeki bir hata ise her yerdedir, çünkü veriyle çalışan her kod satırı yanlış yapıyı varsaymıştır. Daha da kötüsü: Yanlış model veriyle dolar. Sistemin çalıştığı her gün, yanlış biçimde duran veri birikimi büyür — ve bir düzeltmede bu veriyi atamazsınız, dönüştürmeniz gerekir.

Bu, bir veri modelinin neden önceden bu kadar özeni hak ettiğini açıklar: Onu düzeltmek yalnızca bir kod değişikliği değil, mevcut her kaydın, çoğu zaman sistem çalışırken taşınmasıdır — akla gelebilecek en zorlu ve en riskli operasyonlardan biri. Erken ve doğru kurulan bir model bu operasyonu gereksiz kılar; erken ve yanlış kurulan bir model ise onu er geç zorunlu kılar, hem de veri birikiminin büyük ve sistemin kritik olduğu bir anda. Başlangıçta yatırılan özen, bir sistemin bildiği en pahalı onarıma karşı bir sigortadır.

Avantajlar ve sınırlamalar. Yanlış veri modelinin sonraki düzeltme maliyetini dikkate almak, başlangıçta daha yavaş ilerlemeyi gerektirir. Amaç, mevcut veriler üzerinde pahalı dönüşümlerin riskini azaltmaktır.

Maliyet. Baştaki özen, hızla görünür bir şey teslim etme baskısıyla rekabet eder ve karşılığını ancak yıllar içinde verir.

Ne zaman farklı karar veririz. Verilerinin hiçbir zaman taşınması gerekmeyecek, öngörülebilir biçimde kısa ömürlü bir sistemde tam ihtiyat abartıdır; değeri, beklenen ömürle ve veri birikiminin kritikliğiyle artar.

7. Modeli geliştirmek

Bir veri modeli ne kadar kalıcı olursa olsun, değişmez değildir; onu güvenle geliştirebilme yeteneği de uzun ömrünün bir parçasıdır. Bunun disiplini, en riskli değişikliği bile yönetilebilir kılan disiplinle aynıdır: küçük, geri alınabilir adımlarla, mevcut olanı yeniden yapılandırmak yerine eklemeli olarak, eskisi ve yenisi bir süre yan yana. Yeni biçimi eklersiniz, mevcut veriyi doğrulayarak taşırsınız, kodu geçirirsiniz ve eski biçimi ancak artık hiçbir şey ona dayanmadığında kaldırırsınız. Böylece bir model değişikliği, bilinmeze atlayış değil, düzenli bir süreç olarak kalır — sistem çalışırken, kesinti olmadan yürütülür.

Bu gelişim o kadar önemlidir ki tasarımı etkilemelidir: Kolayca eklemeli olarak genişletilebilen bir model, her değişikliği bir yeniden yapılanmaya dönüştüren bir modelden üstündür — ikisi bugün aynı işi görse bile. Veri modelinde de asıl ölçü anlık zarafet değil, değiştirilebilirliktir. Bu doğrulanmış, geri alınabilir taşımanın somut mekaniğini ayrı bir metin ayrıntılı biçimde ele alır; tasarım açısından önemli olan, modeli bu mekaniğin işleyebileceği şekilde en baştan kurmaktır.

Avantajlar ve sınırlamalar. Yeni gereksinimlere açık yapılar, ilk sürüm için en kısa çözüm olmayabilir. Karşılığında model, mevcut yapıyı bozmadan genişletilebilir.

Maliyet. Bir model değişikliği en iyi hazırlıkla bile iş olarak kalır — taşıma, doğrulama, paralel işletim —; bunu hafife almak yerine planlarsınız.

Ne zaman farklı karar veririz. Bir modelin büyük olasılıkla hiçbir zaman genişletilmeyeceği yerde daha kompakt ve daha dar olabilir; değişime hazırlık, alanın öngörülebilir biçimde büyüdüğü yerde karşılığını verir.

8. Model ve kodun birbirinden uzaklaştığı yer

Bir veri modeli aynı anda iki yerde yaşar: veritabanındaki yapı olarak ve onunla çalışan koddaki karşılığı olarak. Bu ikisinin aynı şey hakkında aynı şeyi söylemesi gerekir — ve birbirlerinden bağımsız olarak değiştirilebildikleri için, aralarındaki kopukluk tekrarlayan, sinsi bir hata kaynağıdır. Bir taraf değişip diğeri onu izlemezse, etkisi nedeninden çok uzakta ortaya çıkan ve bu yüzden bulunması zor hatalar oluşur. Koddaki karşılığı ondan sessizce saparsa, kalıcı veri modelinin pek faydası kalmaz.

Tasarım açısından sonuç, bu bağı tek tek kişilerin dikkatine güvenmek yerine görünür ve doğrulanabilir tutmaktır: Yapı ile karşılığı arasındaki bir sapma, geç ve gizemli bir belirti olarak değil, erken ve yüksek sesle fark edilmelidir. Böylece veri modeli yalnızca bir tasarım meselesi değil, aynı zamanda işletimde bir disiplin meselesidir — aynı modelin iki temsilini bir arada tutmak. Bu sessiz bağı ciddiye alan, bütün bir inatçı hata sınıfından kurtulur.

Avantajlar ve sınırlamalar. Model ile kod arasındaki uyumu doğrulamak için ek kontroller gerekir. Bu kontroller de bakım ister; karşılığında sapmalar erken fark edilir.

Maliyet. Her doğrulama bir emektir ve yapıda ya da karşılığında değişiklik yapılan anı biraz daha hantal kılar, çünkü artık ikisinin birbirine uyması gerekir.

Ne zaman farklı karar veririz. Modelini tek bir kişinin rahatça gözetebildiği çok küçük bir sistemde dikkat yeterlidir; güvence, aynı model üzerinde birçok elin çalıştığı andan itibaren karşılığını verir.

9. Tipik hatalar

Veri modellerinin başarısız olduğu tekrarlayan kalıplar — neredeyse hepsi, kalıcı olanı önemsiz bir şeymiş gibi ele almanın varyantlarıdır:

• Modeli alana göre değil arayüze göre biçimlendirmek — ve ilk yeniden tasarımda artık uymadığını fark etmek.
• Framework'e ve veritabanına, ikisini de aşan modelden daha fazla özen göstermek.
• Kimliği kötü seçmek — değişebilir, gerçekten benzersiz olmayan, iş anlamını teknik olanla karıştıran — ve hatayı tüm modele taşımak.
• İlişkileri belirsiz bırakmak ve sonraki düzeltmelerinin bedelini mevcut verinin pahalı dönüşümüyle ödemek.
• Model çelişkilere kayana kadar fark edilmeden yedeklilik biriktirmek.
• Erken aşamada çok fazla şeyi sabitlemek ve düşünülmemiş o tek gereksinim karşısında kırılgan olmak.
• Modeli, eklemeli olarak genişletilebilecek yerde her değişikliğin bir yeniden yapılanma olacağı şekilde kurmak.
• Kimse sessiz bağı görünür kılmadığı için yapının ve koddaki karşılığının birbirinden uzaklaşmasına izin vermek.
• Yanlış bir modelin maliyetini hafife almak ve özeni, en değerli olacağı başlangıçta esirgemek.

10. Karar kontrol listesi

Bir veri modeli tasarlanmadan önce ve tasarlanırken sırasıyla netleştirilmesi gerekenler:

• Alan mı, arayüz mü? Model, şeylerin gerçekte ne olduğunu mu yansıtıyor — yoksa yalnızca bir ekranın o anda gösterdiğini mi?
• Özen doğru dağıtılmış mı? Model, onu aşacak olan framework'ten ve veritabanından daha fazla dikkat görüyor mu?
• Kimlik sağlam mı? Her şey, iş anlamını teknik olanla karıştırmayan, istikrarlı ve gerçekten benzersiz bir şeyle tanımlanıyor mu?
• İlişkiler net mi? Hangi şeylerin birbirleriyle nasıl ilişkili olduğu belirlenmiş mi — ve bu, anlık görünüme değil alana mı sadık?
• Eklemeli olarak genişletilebilir mi? Model, mevcut olanın anlamını kaydırmadan büyüyebiliyor mu?
• Yedeklilik bilinçli mi? Bir olgunun her kopyası istenerek mi var ve onu tutarlı tutan, adı konmuş bir yeri var mı?
• Gelişim düşünülmüş mü? Model, sistem çalışırken küçük, geri alınabilir adımlarla değiştirilebiliyor mu?
• Bağ görünür mü? Yapı ile koddaki karşılığı arasındaki bir kopukluk erken ve nedenine yakın bir yerde fark ediliyor mu?

Bu soruları yanıtlayabilen, ilk değişiklikte esneyip çöken değil, yük taşıyan bir model tasarlamıştır.

Sıkça Sorulan Sorular

Veri modeli neden veritabanı ya da framework seçiminden daha önemlidir? Çünkü ikisini de aşar. Framework'ü güncelleyebilir, arayüzü yeniden inşa edebilir, hatta veritabanını taşıyabilirsiniz; bunların hiçbiri bir müşterinin ne olduğunu ve bir siparişle nasıl ilişkili olduğunu değiştirmez. Verinin biçimi kalır ve üzerindeki her şeyi taşır — bu yüzden uzun ömürlülük üzerinde herhangi bir teknoloji seçiminden daha belirleyicidir.

“Arayüz yerine alanı modellemek” ne demektir? Veriyi, bir formun ya da görünümün o anda gösterdiğine göre değil, şeylerin gerçekte ne olduğuna ve nasıl ilişkilendiğine göre biçimlendirmek. Alana yakın bir model arayüzün her yeniden tasarımını atlatır, çünkü alan sabittir; arayüze yakın bir model ise görüntülemedeki her değişiklikle birlikte yer değiştirmek zorundadır ve kısa sürede bir engele dönüşür.

Kimlik ve ilişkiler neden bu kadar belirleyicidir? Çünkü her şey onların üzerine kurulur ve düzeltilmeleri en pahalı olanlardır. Kötü seçilmiş bir kimlik — değişebilen ya da gerçekten benzersiz olmayan — ona dayanan her referansı zehirler. Yanlış bir ilişkiyi değiştirmek neredeyse her zaman mevcut veriyi dönüştürmek demektir. Bu kararlar en uzun süre dayanır ve en az affeder.

Her zaman katı biçimde normalize etmek mi gerekir? Temel tutum olarak evet, çünkü normalize edilmiş bir model kendisiyle çelişemez. Ama bunun da bir ölçüsü vardır: Ölçülmüş bir okuma yükünün birleştirmeyi fazla pahalı kıldığı yerde bilinçli, kontrollü yedeklilik savunulabilir — yeter ki bunu üstlendiğinizi bilin ve kopyaları kimin tutarlı tuttuğunu açıkça belirleyin. Pahalı olan, çelişkilere kayan bilinçsiz yedekliliktir.

Yanlış bir veri modelini bu kadar pahalı yapan nedir? Her şeyin onun üzerine kurulması ve veriyle dolması. Bir model hatası veriyle çalışan her kod satırını etkiler ve her düzeltme yalnızca bir kod değişikliği değil, mevcut her kaydın taşınmasıdır — çoğu zaman sistem çalışırken. Bir sistemin bildiği en pahalı onarımdır ve baştaki özen buna karşı sigortadır.

Bir veri modeli güvenle nasıl değiştirilir? Küçük, geri alınabilir adımlarla: yeni biçimi eklemeli olarak eklemek, mevcut veriyi doğrulayarak taşımak, kodu geçirmek, eski biçimi ancak artık hiçbir şey ona dayanmadığında kaldırmak — sistem çalışırken, kesinti olmadan. Veritabanı migration'larını yönetilebilir kılan disiplin, modeldeki her değişiklik için de geçerlidir.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — en derin katmanını veri modelinin oluşturduğu temel soru olarak uzun ömürlülük neden önemlidir.
• Uzun ömürlü sistemler için PostgreSQL mi, MySQL mi? — model neden veritabanı seçiminden daha belirleyicidir.
• Kesintisiz veritabanı migration'ları — bir modeli sistem çalışırken geri alınabilir biçimde geliştirmenin mekaniği.
• Şema ve model birbirinden uzaklaştığında — yapı ve koddaki karşılığı sessizce birbirinden saptığında ne olur.

Temel, Batunet Engineering Method'tur: alanı modellemek, değişim için inşa etmek, en kalıcı olana en fazla özeni göstermek.

Temel mühendislik ilkesi

On yıl için bir sistem kuran, önce onun veri modelini kurar — çünkü on yıl kalacağı neredeyse kesin olan tek şey odur. Üzerindeki her şeyi değiştireceksiniz: arayüzü birkaç kez, framework'ü belki, veritabanını muhtemelen. Verinin biçimi hepsinden uzun yaşar, çünkü teknolojiyi değil, sistemin yönettiği gerçekliği yansıtır. Bu yüzden veri modellemesi birçok adımdan biri değil, en derinden taşıyan ve en uzun dayanan karardır. İyi mühendisleri çoğu zaman inşa ettikleri arayüzden değil, arayüz çoktan üç kez değiştirildiğinde hâlâ taşımaya devam eden alttaki modelden tanırsınız.

Arayüz görülen şeydir; veri modeli ise kalan şey. Uzun ömürlü bir sistem aşağıdan yukarıya inşa edilir — ve en altta verinin biçimi yatar.