Domain data

Jala data, pada intinya, didirikan dalam desentralisasi dan distribusi tanggung jawab ke domain. Jika Anda benar-benar memahami bagian dari bisnis ini, Anda paling baik diposisikan untuk mengelola data terkait dan memastikan akurasinya. Ini adalah prinsip kepemilikan data berorientasi domain.

Untuk mempromosikan kepemilikan data berorientasi domain, Anda harus terlebih dahulu membuat dekomposisi arsitektur data Anda. Pendiri jala data Zhamak Dehghani mempromosikan pendekatan Domain-Driven Design (DDD) untuk pengembangan perangkat lunak sebagai metode yang berguna untuk membantu Anda mengidentifikasi domain data Anda.

Kesulitan menggunakan DDD untuk manajemen data adalah bahwa kasus penggunaan asli DDD adalah memodelkan sistem yang kompleks dalam konteks pengembangan perangkat lunak. Ini awalnya tidak dibuat untuk memodelkan data perusahaan, dan untuk praktisi manajemen data metodenya dapat abstrak dan teknis. Sering juga ada kurangnya pemahaman tentang DDD. Praktisi menemukan gagasan konseptualnya terlalu sulit dipahami, atau mencoba memproyeksikan contoh dari arsitektur perangkat lunak atau pemrograman berorientasi objek ke lanskap data mereka. Artikel ini memberi Anda panduan pragmatis dan kosakata yang jelas sehingga Anda dapat memahami dan menggunakan DDD.

Desain Berbasis Domain

Diperkenalkan oleh Eric Evans, Domain-Driven Design adalah metode untuk mendukung pengembangan perangkat lunak yang membantu menggambarkan sistem kompleks untuk organisasi yang lebih besar. DDD populer karena banyak praktik tingkat tingginya berdampak pada pendekatan pengembangan perangkat lunak dan aplikasi modern untuk hal-hal seperti layanan mikro.

DDD membedakan antara konteks, domain, dan subdomain terikat. Domain adalah ruang masalah yang ingin Anda atasi. Mereka adalah area di mana pengetahuan, perilaku, hukum, dan kegiatan bersatu. Anda melihat kopling semantik di domain, dependensi perilaku antara komponen atau layanan. Aspek lain dari domain adalah komunikasi. Anggota tim harus menggunakan bahasa yang dibagikan seluruh tim sehingga semua orang dapat bekerja secara efisien. Bahasa bersama ini disebut bahasa ataubahasa domain mana-mana.

Domain diurai menjadi subdomain untuk mengelola kompleksitas dengan lebih baik. Contoh umum dari ini adalah menguraikan domain menjadi subdomain yang masing-masing sesuai dengan satu masalah bisnis tertentu seperti yang ditunjukkan dalam Mengoptimalisasi jala data untuk AI/ML.

Tidak semua subdomain sama. Anda dapat, misalnya, mengklasifikasikan domain menjadi inti, generik, atau pendukung. Subdomain inti adalah yang paling penting. Mereka adalah saus rahasia, bahan-bahan, yang membuat organisasi unik. Subdomain generik bersifat nonspesifikasi, dan biasanya mudah dipecahkan dengan produk di luar rak. Subdomain pendukung tidak menawarkan keunggulan kompetitif, tetapi perlu untuk menjaga organisasi tetap berjalan, dan biasanya tidak kompleks.

Konteks terikat adalah batas logis (konteks). Mereka fokus pada ruang solusi: desain sistem dan aplikasi. Ini adalah area di mana penyelarasan fokus pada ruang solusi masuk akal. Dalam DDD, ini dapat mencakup kode, desain database, dan sebagainya. Antara domain dan konteks terikat, mungkin ada penyelarasan, tidak ada aturan keras yang mengikat keduanya bersama-sama. Konteks terikat bersifat teknis dan dapat mencakup beberapa domain dan subdomain.

Rekomendasi pemodelan domain

Jika Anda mengadopsi jala data sebagai konsep untuk demokratisasi data, dan menerapkan prinsip kepemilikan data berorientasi domain untuk meningkatkan fleksibilitas, bagaimana cara kerja ini dalam praktiknya? Seperti apa transisi dari pemodelan data perusahaan ke pemodelan desain berbasis domain? Pelajaran apa yang dapat Anda ambil dari DDD untuk manajemen data?

Membuat penguraian bisnis fungsian dari ruang masalah Anda

Sebelum memungkinkan tim Anda mengoperasikan data mereka secara menyeluruh, lihat cakupan dan pahami ruang masalah yang ingin Anda atasi. Penting untuk melakukan latihan ini terlebih dahulu sebelum Anda melompat ke detail implementasi teknis. Ketika Anda mengatur batas logis antara ruang masalah ini, tanggung jawab menjadi lebih jelas dan dapat dikelola dengan lebih baik.

Lihat arsitektur bisnis Anda saat mengelompokkan ruang masalah Anda. Dalam arsitektur bisnis, ada kemampuan bisnis: kemampuan atau kapasitas yang dimiliki atau ditukar bisnis untuk mencapai tujuan atau hasil tertentu. Abstraksi ini mengemas data, proses, organisasi, dan teknologi ke dalam konteks tertentu, selaras dengan tujuan dan tujuan bisnis strategis organisasi Anda. Peta kemampuan bisnis menunjukkan area fungsi yang tampaknya diperlukan untuk memenuhi misi dan visi Anda.

Anda dapat melihat penguraian kemampuan perusahaan fiktif, Tailwind Traders, dalam model berikut.

Tailwind Traders perlu menguasai semua area fungsional yang tercantum dalam Peta Kemampuan Bisnis agar berhasil. Tailwind Traders harus dapat menjual tiket sebagai bagian dari Sistem Manajemen Tiket Online atau Offline, misalnya, atau memiliki Pilot yang tersedia untuk menerbangkan pesawat sebagai bagian dari Program Manajemen Pilot. Perusahaan dapat mengalihdayakan beberapa kegiatan sambil menjaga orang lain sebagai inti bisnisnya.

Apa yang akan Anda amati dalam praktiknya adalah bahwa sebagian besar orang Anda diatur di sekitar kemampuan bisnis. Orang bekerja pada kemampuan bisnis yang sama berbagi kosakata yang sama. Hal yang sama berlaku untuk aplikasi dan proses Anda, yang biasanya selaras dengan baik dan terhubung erat berdasarkan kohesi aktivitas yang mereka dukung.

Pemetaan kemampuan bisnis adalah titik awal yang bagus, tetapi cerita Anda tidak berakhir di sini.

Memetakan kemampuan bisnis ke aplikasi dan data

Untuk mengelola arsitektur perusahaan Anda dengan lebih baik, selaraskan kemampuan bisnis, konteks terikat, dan aplikasi Anda. Penting untuk mengikuti beberapa aturan dasar saat Anda melakukannya.

Kemampuan bisnis harus tetap berada di tingkat bisnis dan tetap abstrak. Mereka mewakili apa yang dilakukan organisasi Anda dan menargetkan ruang masalah Anda. Saat Anda menerapkan kemampuan bisnis, realisasi (instans kemampuan) untuk konteks tertentu dibuat. Beberapa aplikasi dan komponen bekerja sama Dalam batas-batas tersebut di ruang solusi Anda untuk memberikan nilai bisnis tertentu.

Aplikasi dan komponen yang selaras dengan kemampuan bisnis tertentu tetap dipisahkan dari aplikasi yang selaras dengan kemampuan bisnis lainnya, karena mengatasi masalah bisnis yang berbeda. Konteks terikat berasal dari dan dipetakan secara eksklusif ke kemampuan bisnis. Mereka mewakili batas implementasi kemampuan bisnis, dan mereka bereaksi seperti domain.

Jika kemampuan bisnis berubah, konteks terikat berubah. Anda sebaiknya mengharapkan perataan penuh antara domain dan konteks terikat yang sesuai, tetapi karena Anda akan belajar di bagian selanjutnya, realitas terkadang berbeda dari yang ideal.

Jika kita memproyeksikan pemetaan kemampuan ke Tailwind Traders, batas konteks terikat dan implementasi domain mungkin terlihat mirip dengan diagram berikut.

Dalam diagram ini, Manajemen pelanggan dibangun berdasarkan keahlian subjek dan oleh karena itu tahu data apa yang paling baik untuk dilayani ke domain lain. Arsitektur dalam manajemen pelanggan dipisahkan, sehingga semua komponen aplikasi dalam batas-batas ini dapat langsung berkomunikasi menggunakan antarmuka dan model data khusus aplikasi.

Produk data dan standar interoperabilitas yang jelas digunakan untuk meresmikan distribusi data ke domain lain. Dalam pendekatan ini, semua produk data juga selaras dengan domain dan mewarisi bahasa yang di mana-mana, yang merupakan bahasa yang dibangun dan diformalkan yang disepakati oleh pemangku kepentingan dan desainer dari domain yang sama, untuk melayani kebutuhan domain tersebut.

Domain tambahan dari beberapa realisasi kemampuan

Penting untuk diakui ketika bekerja dengan peta kemampuan bisnis bahwa beberapa kemampuan bisnis dapat diinstansiasi beberapa kali.

Sebagai contoh, Tailwind Traders mungkin memiliki beberapa realisasi yang dilokalkan (atau implementasi) dari "penanganan bagasi dan item yang hilang". Asumsikan satu lini bisnis mereka hanya beroperasi di Asia. Dalam konteks ini, "penanganan bagasi dan barang yang hilang" adalah kemampuan yang dipenuhi untuk pesawat terkait Asia. Lini bisnis yang berbeda mungkin menargetkan pasar Eropa, dan dalam konteks ini kemampuan "penanganan bagasi dan barang hilang" lainnya digunakan. Skenario beberapa instans ini dapat menyebabkan beberapa implementasi lokal menggunakan layanan teknologi yang berbeda dan tim yang tidak bergabung untuk mengoperasikan layanan tersebut.

Hubungan kemampuan bisnis dan instans kemampuan (realisasi) adalah satu-ke-banyak. Karena itu, Anda berakhir dengan domain tambahan (sub-).

Temukan kemampuan bersama dan perhatikan data bersama

Cara Anda menangani kemampuan bisnis bersama penting. Anda biasanya menerapkan kemampuan bersama secara terpusat, sebagai model layanan, dan menyediakannya ke lini bisnis yang berbeda. "Manajemen pelanggan" dapat menjadi contoh kemampuan semacam ini. Dalam contoh Tailwind Traders kami, lini bisnis Asia dan Eropa menggunakan administrasi yang sama untuk klien mereka.

Tetapi bagaimana Anda dapat memproyeksikan kepemilikan data domain pada kemampuan bersama? Beberapa perwakilan bisnis kemungkinan bertanggung jawab untuk pelanggan yang dalam administrasi bersama yang sama.

Ada domain aplikasi dan domain data. Domain Anda dan konteks terikat tidak selaras dengan sempurna dari titik pandang produk data. Anda dapat membantah bahwa masih ada satu kekhawatiran data dari sudut pandang kemampuan bisnis.

Untuk kemampuan bersama seperti paket vendor yang kompleks, solusi SaaS, dan sistem warisan, konsisten dalam pendekatan kepemilikan data domain Anda. Anda dapat memisahkan kepemilikan data melalui produk data, yang mungkin memerlukan peningkatan aplikasi. Dalam contoh "manajemen pelanggan" Tailwind Traders kami, alur yang berbeda dari domain aplikasi dapat menghasilkan beberapa produk data: satu produk data untuk semua pelanggan terkait Asia, dan satu untuk semua pelanggan terkait Eropa. Dalam situasi ini, beberapa domain data berasal dari domain aplikasi yang sama.

Anda juga dapat meminta domain aplikasi Anda untuk membuat satu produk data yang merangkum metadata untuk membedakan kepemilikan data dalam dirinya sendiri. Anda dapat, misalnya, memesan nama kolom untuk kepemilikan, memetakan setiap baris ke satu domain data tertentu.

Mengidentifikasi monolit yang menawarkan beberapa kemampuan bisnis

Perhatikan juga aplikasi yang memenuhi beberapa kemampuan bisnis, yang sering terlihat di perusahaan besar dan tradisional. Dalam skenario contoh kami, Tailwind Traders menggunakan paket perangkat lunak yang kompleks untuk memfasilitasi "cost management" dan "aset dan pembiayaan". Aplikasi bersama ini adalah monolit yang menyediakan fitur sebanyak mungkin, membuatnya besar dan kompleks. Dalam situasi seperti itu, domain aplikasi harus lebih besar. Hal yang sama berlaku untuk kepemilikan bersama, di mana beberapa domain data berada di domain aplikasi.

Pola desain untuk domain yang selaras dengan sumber, redelivery, dan selaras dengan konsumen

Saat memetakan domain, Anda dapat memilih pola berdasarkan pembuatan, konsumsi, atau penelurusan ulang data Anda. Untuk arsitektur Anda, Anda dapat merancang templat yang mendukung domain Anda berdasarkan karakteristik spesifik domain.

Domain yang selaras dengan sistem sumber

Domain yang selaras dengan sistem sumber selaras dengan sistem sumber tempat data berasal. Sistem ini biasanya transaksi atau operasional.

Tujuan Anda adalah untuk mengambil data langsung dari sistem sumber emas ini. Baca-optimalkan produk data dari domain yang Anda sediakan untuk konsumsi data intensif. Memfasilitasi domain ini menggunakan layanan standar untuk transformasi dan berbagi data.

Layanan ini, yang mencakup struktur kontainer yang telah dikonfigurasi sebelumnya, memungkinkan tim domain berorientasi sumber Anda untuk menerbitkan data dengan lebih mudah. Ini adalah jalur ketahanan paling sedikit dengan gangguan dan biaya minimal.

Domain yang selaras dengan konsumen

Domain yang selaras dengan konsumen adalah kebalikan dari domain yang selaras dengan sumber. Mereka selaras dengan kasus penggunaan pengguna akhir tertentu yang memerlukan data dari domain lain. Domain yang selaras dengan pelanggan menggunakan dan mengubah data agar sesuai dengan kasus penggunaan organisasi Anda.

Pertimbangkan untuk menawarkan layanan data bersama untuk transformasi dan konsumsi data untuk memenuhi kebutuhan konsumsi ini. Anda dapat menawarkan kemampuan infrastruktur data agnostik domain, misalnya, untuk menangani alur data, infrastruktur penyimpanan, layanan streaming, pemrosesan analitik, dan sebagainya.

Domain redelivery

Penggunaan kembali data adalah skenario yang berbeda dan lebih sulit. Misalnya, jika konsumen hilir tertarik pada kombinasi data dari domain yang berbeda, Anda dapat membuat produk data yang menggabungkan data atau menggabungkan data tingkat tinggi yang diperlukan oleh banyak domain. Ini memungkinkan Anda untuk menghindari pekerjaan berulang.

Jangan membuat dependensi yang kuat antara produk data Anda dan kasus penggunaan analitis. Berusahalah untuk fleksibilitas dan konektivitas longgar sebagai gantinya. Model berikut menunjukkan bagaimana Anda dapat mencapai fleksibilitas. Domain mengambil kepemilikan untuk produk data dan kasus penggunaan analitis, dan telah merancang proses terpisah untuk pembuatan produk data dan penggunaan data.

Menentukan pola domain yang tumpang tindih

Pemodelan domain sering kali menjadi rumit saat logika data atau bisnis dibagikan di seluruh domain. Di organisasi skala besar, domain sering mengandalkan data dari domain lain. Sangat membantu untuk memiliki domain generik yang menyediakan logika integrasi dengan cara yang memungkinkan subdomain lain untuk menstandarkan dan mendapatkan manfaat darinya. Jaga agar model bersama Anda antara subdomain tetap kecil dan selalu selaras dengan bahasa yang ada di mana-mana.

Untuk persyaratan data yang tumpang tindih, Anda dapat menggunakan pola yang berbeda dari desain berbasis domain. Berikut adalah ringkasan singkat pola yang dapat Anda pilih:

• Pola cara terpisah dapat digunakan jika Anda lebih memilih biaya duplikasi terkait daripada penggunaan kembali. Penggunaan kembali dikorbankan untuk fleksibilitas dan kelincahan yang lebih tinggi.
• Pola pemasok pelanggan dapat digunakan jika satu domain kuat dan bersedia untuk mengambil kepemilikan data dan kebutuhan konsumen hilir. Kelemahan termasuk masalah yang bertentangan dan memaksa tim hilir Anda untuk menegosiasikan hasil kerja dan menjadwalkan prioritas.
• Pola kemitraan dapat digunakan saat logika integrasi Anda dikoordinasikan dengan cara yang tidak diencana dalam domain yang baru dibuat. Semua tim bekerja sama dan memperhatikan kebutuhan masing-masing. Karena tidak ada yang dapat dengan bebas mengubah logika bersama, diperlukan komitmen signifikan dari semua orang yang terlibat.
• Pola yang sesuai dapat digunakan untuk menyesuaikan semua domain Anda dengan semua persyaratan. Gunakan pola ini ketika pekerjaan integrasi Anda kompleks, tidak ada pihak lain yang dapat memiliki kontrol, atau Anda menggunakan paket vendor.

Dalam semua kasus, domain Anda harus mematuhi standar interoperabilitas Anda. Domain kemitraan yang menghasilkan data baru untuk domain lain harus mengekspos produk data mereka seperti domain lain, termasuk mengambil kepemilikan.

Tanggung jawab domain

Jala data mendesentralisasi kepemilikan data dengan mendistribusikannya di antara tim domain. Bagi banyak organisasi, ini berarti pergeseran dari model terpusat sekeliling tata kelola ke model federasi. Tim domain diberi tugas, seperti:

• Mengambil kepemilikan alur data, seperti penyerapan, pembersihan, dan transformasi data, untuk melayani kebutuhan pelanggan data sebanyak mungkin
• Meningkatkan Kualitas Data, termasuk kepatuhan terhadap SLA dan langkah-langkah kualitas yang ditetapkan oleh konsumen data
• Merangkum metadata atau menggunakan nama kolom khusus untuk pemfilteran baris dan tingkat kolom halus
• Mematuhi standar manajemen metadata, termasuk:
  • Pendaftaran skema sistem aplikasi dan sumber
  • Metadata untuk meningkatkan kemampuan penemuan
  • Informasi penerapan versi
  • Tautan atribut data dan istilah bisnis
  • Integritas informasi metadata untuk memungkinkan integrasi yang lebih baik antar domain
• Mematuhi standar interoperabilitas data, termasuk protokol, format data, dan jenis data
• Menyediakan silsilah data baik dengan menautkan sistem sumber dan layanan integrasi ke pemindai atau dengan menyediakan silsilah data secara manual
• Mematuhi tugas berbagi data, termasuk tinjauan akses IAM dan pembuatan kontrak data

Tingkat granularitas untuk pemisahan

Sekarang Anda tahu cara mengenali dan memfasilitasi domain data, Anda dapat belajar merancang tingkat granularitas domain dan aturan yang tepat untuk pemisahan. Dua dimensi penting sedang dimainkan saat Anda mengurai arsitektur Anda.

Granularitas untuk domain fungsional dan mengatur konteks terikat adalah satu dimensi. Domain sesuai dengan cara kerja tertentu, memastikan data tersedia untuk semua domain menggunakan layanan bersama, mengambil kepemilikan, mematuhi standar metadata, dan sebagainya.

Atur batas-batas halus jika memungkinkan untuk distribusi data. Menjadi berbasis data adalah tentang membuat data tersedia untuk digunakan kembali secara intensif. Jika Anda membuat batas terlalu longgar, Anda akan memaksa konektivitas yang tidak diinginkan antara banyak aplikasi dan kehilangan penggunaan kembali data. Berusaha untuk memisahkan setiap kali data melewati batas kemampuan bisnis. Dalam domain, kopling ketat dalam arsitektur dalam domain diizinkan. Namun, saat melintasi batas kemampuan bisnis, domain harus tetap dipisahkan dan mendistribusikan produk data yang dioptimalkan untuk dibagikan dengan domain lain.

Granularitas untuk domain teknis dan pemanfaatan infrastruktur adalah dimensi penting lainnya. Zona pendaratan data Anda memungkinkan kelincahan untuk melayani aplikasi data, yang membuat produk data. Bagaimana Anda membuat zona pendaratan semacam ini dengan infrastruktur dan layanan bersama di bawahnya? Domain fungsional dikelompokkan secara logis dan merupakan kandidat yang baik untuk berbagi infrastruktur platform. Berikut adalah beberapa faktor yang perlu dipertimbangkan saat membuat zona pendaratan ini:

• Kohesi dan efisiensi saat bekerja dengan dan berbagi data adalah pendorong yang kuat untuk menyelaraskan domain fungsional ke zona pendaratan data. Ini berkaitan dengan gravitasi data, kecenderungan untuk terus berbagi produk data besar antar domain.
• Batas regional dapat mengakibatkan zona pendaratan data tambahan diterapkan.
• Kepemilikan, keamanan, atau batas hukum dapat memaksa pemisahan domain. Misalnya, beberapa data tidak dapat dilihat oleh domain lain.
• Fleksibilitas dan kecepatan perubahan adalah pendorong penting. Beberapa domain dapat memiliki kecepatan inovasi yang tinggi, sementara domain lain sangat menghargai stabilitas.
• Batas fungsi dapat memisahkan tim. Contohnya dapat berupa batas berorientasi sumber dan berorientasi konsumen. Setengah dari tim domain Anda mungkin menghargai layanan tertentu daripada yang lain.
• Jika Anda ingin berpotensi menjual atau memisahkan kemampuan, Anda harus menghindari integrasi erat dengan layanan bersama dari domain lain.
• Ukuran, keterampilan, dan kematangan tim semuanya bisa menjadi faktor penting. Tim yang sangat terampil dan matang sering lebih suka mengoperasikan layanan dan infrastruktur mereka sendiri, sementara tim yang kurang matang cenderung tidak menghargai overhead ekstra pemeliharaan platform.

Sebelum Anda menyediakan banyak zona pendaratan data, lihat dekomposisi domain Anda dan tentukan domain fungsional apa yang menjadi kandidat untuk berbagi infrastruktur yang mendasar.

Ringkasan

Pemodelan kemampuan bisnis membantu Anda mengenali dan mengatur domain Anda dengan lebih baik dalam arsitektur jala data. Ini memberikan pandangan holistik tentang cara data dan aplikasi memberikan nilai untuk bisnis Anda, sementara pada saat yang sama membantu Anda memprioritaskan dan fokus pada strategi data dan kebutuhan bisnis Anda. Anda juga dapat menggunakan pemodelan kemampuan bisnis untuk lebih dari sekadar data. Misalnya, jika skalabilitas menjadi perhatian, Anda dapat menggunakan model ini untuk mengidentifikasi kemampuan inti Anda yang paling penting dan mengembangkan strategi untuk mereka.

Beberapa praktisi menimbulkan kekhawatiran bahwa membangun arsitektur status target dengan memetakan segala sesuatu di depan adalah latihan intensif. Sebaliknya, mereka menyarankan Anda mengidentifikasi domain Anda secara organik saat Anda memasukkannya ke dalam arsitektur jala data baru Anda. Alih-alih menentukan status target Anda dari atas ke bawah, Anda bekerja di bawah ke atas, menjelajahi, bereksperimen, dan transisi status Anda saat ini menuju status target. Meskipun pendekatan yang diusulkan ini mungkin lebih cepat, pendekatan ini membawa risiko yang signifikan. Anda dapat dengan mudah berada di tengah-tengah operasi pemindahan atau renovasi yang kompleks ketika hal-hal mulai rusak. Bekerja dari kedua arah, atas ke bawah dan bawah ke atas, dan kemudian bertemu di tengah dari waktu ke waktu adalah pendekatan yang lebih bernuansa.

Langkah selanjutnya

• Apa itu produk data?