Struktur Folder Aplikasi Harusnya Kayak Gini | PZN Reaction
Вставка
- Опубліковано 19 сер 2024
- Struktur Folder Aplikasi Harusnya Kayak Gini | PZN Reaction
Link : / danielmoka_if-you-look...
#programmerzamannow #pznreaction #pznreact
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
UA-cam : / programmerzamannow
saya setuju sama yg behind the scene kang wkwk
kalo monolith, pake tech driven di dalem feature driven itu saya cocok. Kaya dulu pas jaman pake CI3 itu dia MVC, tp ada orang yg fork dan restructure jadi HMVC. Yaa kurang lebih yg gambar behind the scene itu persis kaya HMVC. Jd MVC per modul/fitur/domain.
kalo buat microservice, yaudah tinggal si modul/fitur/domain yg di atas barusan dikeluarin aja. Ini harusnya simpel kl emg udh independen dan ga depend sama yg lainnya, kl masi agak berantakan si yaa tinggal refactor2 aja buat jd microservice hahaha
🎉🎉🎉
baru mau komen gini juga, simplenya MVC dan HMVC.
yak betul HMVC sistem modular wrapping mvc
Tech Driven ---> khusus menggunakan Framework
Feature Driven ---> Khusus Native languages
Jadi tergantung developernya juga mau pake yang mana. Yang jelas jgn dipaksain spt
Framework tapi maksain Tech Driven
Native languages tapi bikin tech driven....
Pasti developer penerusnya akan kesulitan utk tracking ato ngembangin
Pemilihan tech or domain driven menurut saya tergantung dari project itu sendiri. Contohnya saya masih handle legacy code web base dengan banyak modul, saya merasa nyaman menggunakannya karena memang pada jamannya programmer yang menjalankan code tersebut tidak mengenal istilah struktur folder, karena kebanyakan programmer dikantor saya memang diawali dari seorang teknisi komputer, berlanjut jadi network engineer, dan menjadi programmer. Istilah kerennya mesti serba bisa, dan untuk deliver semua dengan cepat ya per modul lebih oke.
selama jadi programmer di software house, pake tech-driven udah cukup sih. utamanya bisa deliver app ke client dan maintenance nya juga ga terlalu pusing, mungkin karena udah kebiasaan. ga tau ya kalau yang di startup kaya gimana, belum pernah masuk ke company product base
Salah satu kelemahan software engineering adalah miskin empirical evidence, hampir semua hanya didasari gut feelings.
Bukan bang.
Lebih tepatnya software engineering itu terlalu cepat berkembangnya.
Gampang banget outdated, padahal itu baru 1 years old.
Coba bandingkan dengan engineering yang lain.
Teknologi yang mereka pakai udah lama banget.
Transmisi CVT misalnya, dah ada dari tahun 1870.
Dan bandingkan dengan Java.
Java 8 itu dah outdated banget, sekarang mainstream nya pake java 17 dengan Springboot 3.
Cuman perusahaan besar yang masih simpen legacy code yang pake teknologi ini.
Padahal java 8 rilis tahun 2014, belum sampe 10 tahun.
@@friedec3622 kl kita bicara hal fundamental, sama saja di software engineering jg hampir tidak ada perubahan selama puluhan tahun. Makanya jika belajar, disarankan untuk ambil fundamentalnya.
@@friedec3622 terlalu cepat berkembang dalam hal add ons nya aja, semuanya balik lagi ke fudamental yang sama, (Presenter Business Logic Model) ataupun even basic nya lagi (I/O Processor Storage). mau itu MVVC, MVP, MVC, dll.
Menurut saya bukan masalah following the trend nya, tapi lebih ke consensus bersama aja. Even itu legacy code, tapi kalau secara maturity sudah proven code complexity nya gak increase secara eksponensial dan maintainable, kenapa musti pindah ke yang lebih hype. Ini lebih ke idealisme new engineer sama realitas senior engineer.
Lah kantor2 yg saya pegang masih pake sql server 2008 😅
@@gilangprambudi354 nah bener...
sederhananya lebih mentingin keindahannya aja ketimbang fungsionalnya...
Basically layered architecture vs vertical slicing architecture. Selalu ada plus minusnya walau yg kanan sekarang lagi populer.
Menit pertama yg saya bayangin ya seperti gambar di behind the scene itu 😂 di masing-masing modul/domain ya bakal ada mvc nya juga
IMO, Problem dari Tech Driven adalah maintenance invariant yang terasa awkward, apalagi jika satu entity memiliki role berbeda tergantung konteks domain (misal examinee dan payor merupakan role dari satu akun yang sama tapi memiliki invariant dan properti yang berbeda tergantung konteks domain).
Domain driven memetakan satu akun menjadi role-rolenya tersendiri sesuai konteks domain jadi kita bisa berbicara tentang akun sesuai konteksnya apa.
Jika menggunakan MVC seringkali batasan domain ini engga ada, model yang seharusnya bertanggung jawab terhadap invariant seringkali malah jadi jembatan repository yang akhirnya, IME, model dibatasi rancangan database. Ketika kita berbicara mengenai domain problem kita engga bisa lagi hanya dengan melihat dari modelnya saja.
untuk monolitik saya cenderung ke tech driven. kalau mau feature driven, sekalian ke microservice aja. karena pemisahan domain dan lain2nya pasti perlu konsiderasi juga.
mengenai feature driven, yang saya paling penasaran adalah database mappingnya bagaimana. kalau tidak dipisahkan schema databasenya, akan tetep ada underlying dependency between the features.
TLDR, kalau monolitik pilih tech driven. kalau mau feature driven, microservice aja dengan benar.
Bahasa pemrograman seperti Go bisa mendeteksi adanya circular dependency.
Akibatnya? Program tidak bisa dijalankan/di-build.
tergantung project kebutuhannya gimana dan seberapa besar projectnya, kalo small medium tech driver masih sangat ok, feature driven lebih cocok kalau untuk di frontend
menurutku lebih cocok tech driven sih, lebih mudah jg bagi pemula dan debugging, lebih familiar jg untuk semua framework yang menerapkan MVC, misal ada error kan kalo pake MVC otomatis gampang kita racing error ke rout dulu, liat controllernya dimana, di controller liat modelnya dimana, kalo tiba2 pake feature/domain driven, malah susah terutama pemula mau debuggingnya
Setuju, menarik bahasannya, memang dengan struktur folder yang baik di aplikasi menjadi penting dalam pengembangan kedepan
saya si setuju. sering banget pas onbording coding kadang bingung ni fitur kemana aja, modelnya apa aja, service nya apa aja, controller ada di mana, dsb. kalau feature driven emang to the point
sy jg sih.skrg kalau buat aplikasi itu di buat per module.
semenjak sy pakai nest js. ketika pindah ke yang lain sprti express atau lainnya. sy buat permodule. apalagi buat kerja tim. lebih mudh.
nnti kalau ada module yang mau di shere . tinggl di infokan sj sih. kalau kita.
Saya awalnya belajar pemrograman pake Python dan buat backend pake Django. Jujur saya suka sih sama struktur folder nya jelas aja gitu per folder dari aplikasi kesuluruhan nya ttg fitur apa. Sekarang saya sudah terbiasa pake laravel tapi ya tetap aja masih kepengen struktur folder kayak di django
Cakep, selalu suka sama bahasan selain language dan framework seperti ini. Terimakasih banyak Pak
Dulu saya pernah pake feature driven, tujuannya seperti yang disebutkan Daniel. Tapi pada akhirnya sulit kalau feature A butuh feature B, kemudian nanti riskan ada cyclic dependency. Akhirnya sekarang balik ke tech driven
Bener bgt, ini yg selalu sy pikirin. Bakal pusing ngatur dependencynya kalo struktur foldernya berdasarkan domain
Ngakak online 10:05
Dalam kasus tertentu juga berlaku untuk tech driven yang isinya dibagi permodul.
Untuk meminimalkan kekeliruan ada baiknya memang ngikutin pattern dari framework yang kita gunakan.
Yang paling penting kita tau apa yang sedang kita kerjakan dan akan lebih baik lagi jika kita tau apa yang akan kita kerjakan.
Dan pembuatan software besar dgn multi domain itu lbh pas dgn domain feature folder.
Klo ada masalah sama circular dependency, mungkin perlu ditinjau lgi domainnya.
Karena dgn fitur folder kyk gini, akan promote loosely coupling arch
Di sini pentingnya domain discovery sebelon membuat software. Jdi masalah2 di feature driven lbh mudah diatasi di depan
Kalau saya sih setuju menggabungkan keduanya... Terutama untuk project besar yang monolith. Kalau di CodeIgniter yang basisnya MVC, bisa pakai addon HMVC untuk base frameworknya
Mw kiri atau yg kanan bebas aja, yg penting sih ada unit test nya, terlebih utk yg bisnis proses utamanya dibuat test case. 😊
itu kurang tepat implementing tentang scream architecture.. scream architecture harusnya ada di business logic case, yang mana bisa 100% di cover dengan unit test... ketika di buka unit test/business logic folder nya terjadi fenomena orgasme otak scream architecture... klo struktur folder project, ya masih pake layering technology/resposiblity. kalaupun mau domain driven bisa aja tapi jadi mono repo, dalam nya tetap aja ada layering technology.
Saya di backend pake layer first / tech driven, sedangkan disisi frontend pake feature driven.
ini pendekatannya yg dibahas adl service dan modul.. krn kl kasusnya prog 1 prog multi sub prog.. ujungnya metode 1
kl udah bikin metode 2 butuh pengembangan..
07:16 Jadiin materi terpisah mas Eko, untuk menghindari cyclic dependency antar module nya. Lagi mengalaminya nih 😆
mantap om, sering seringin aja bikin konten kek gini wkwk
kalau di indo si kebanyakan masih tech driven ya, saya liat yg pake domain driven jg jarang, apalagi itu feature driven, apalagi konsep spring yg udah gitu repo service controller, dan juga kalau sekarang kayanya udah di bagi domain per service juga, jadi ga perlu per feature gitu
udah dari dulu pakai feature driven. lebih nyaman aja 😀
Kalau dibuat feature driven, gimana implementasi sharing module atau function yang reusable?
Untuk Monolith So Far saya fine dengan Tech-Driven malah jadinya agak aneh sendiri kalau ke Feature-Driven,
Tapi kalau untuk Microservices sudah jelas Feature-Driven adalah basis utamanya.
Kalo aplikasinya monolith cocok sih, tapi kalo aplikasinya dipecah2 ke banyak project misal untuk microservices, 1 module 1 project lebih cocok tech driven.
mungkin lebih tepatnya, satu prefix API (kalau backend) satu folder, kemudian ada folder lib dan folder helper terpisah
iya intinya modular tiap modularnya ada mvc dan api nya dll saya sdh seperti itu dari dulu sampe skr
saya 2021 pernah kerja sama ama orang ukrain buat bikin fitur di server game, jadi moduler nya itu berdasarkan nama fiturnya
seriously? kalo menurut saya keduanya bener-bener aja, tergantung pake frameworknya apa sama CLI yang nge generate strukturnya. Yang penting team sudah tau bagaimana kesepakatan struktur yang dipakai. Kalo soal ribet keduanya bakal ribet aja kalo IDE yang dipake busuk.
Request ulang bahas encryption at rest dong 😁
Feature Driven juga di dalam tiap foldernya kan filenya dipisah pakai Tech Driven.
tapi mau se modular apapun di layer app nya.. tetap aja di database nya high coupling kalo masih monolith. 😭
kalo strukturnya featured driven trus naro cron sama config file dimana? payment procesor ada cron, support center ada cron, mencar2 jadinya
Mau pake yang manapun, yang penting aplikasinya jalan 😊
kalau kejar tayang, jdi feature driven wkwkwkk
pernah coba pakai feature driven, nah dependency nya itu yg bikin pusing. beberapa bahasa pemrograman tidak memperbolehkan itu
djanggo itu pakai yg 1 nya itu,, tiap domain ada 1 folder dan subfoder, tp pemahaman juga agak susah menurutku..
menarik nih. request bahas monorepo juga pak 🙏
Enakan yg tech driven strukturnya mudah di pelajari, apalagi buat saya yg pemula hehe ✌
tapi bakal jadi lompat sana lompat sini pas nge develop fitur baru
Saya belum ngerti masalah ini. Tapi aku mau tanya, framework Django termasuk yang mana menurut pembahasan ini?
kerasa banget challenge yang dihadapi tim setelah pake feature driven jadinya dependency dan cyclic import issues, akhirnya ya dicampur antara structur tech driven dan feature domain wkwkwk
bisa di buat outbond aj untuk per fiturnya, jadi ketika fitur A membutuhkan sesuatu dari fitur B, maka B menyediakan outbond, jadi A akses via outbond.
django by default udah per fitur pembagian foldernya
jadi inget pas develop desktop app. iya kan?
sama aja isi nya MVC juga tiap feature
10:18 itu kaya HMVC ya, saya kurang lebih kaya gitu soalnya 😁
apakah bisa disimpulkan "nge-monolith-in microservice"? :)
misal pake express generator gimana bang soalnya kan express itu setau saya mengusung unopinionated framework
kalau pake framework macam laravel apa ga kerepotan tuh ngerename folder satu2?
Sesuaikan sama kebutuhan saja, ga saklek harus diikuti
Ini yang kutunggu tunggu
case kayak diatas bukannya lebih cocok pake monorepo ya ?
bang tanya dong. gimana ya cara kita menentukan API ini masuk ke modul A atau modul B? Soalnya selama ini tuh saya bikin modul selalu ngikutin table DB. Alhasil bikin banyak banget modul nya
Anggap saja dibagi per fitur. misal payment, user, atau mungkin streaming. dari 3 feature tersebut biasanya menggunakan beberapa table.
Ikut tanya bang, klo yg Feature-driven itu contohnya kaya Django bukan bang?
Klo topic seperti ini apakah termasuk area disiplin ilmu software architect bukan? 🙂
ini sih HMVC
bang eko, ada tips biar skill problem solving terasah?
Main main ke hacker rank atau sejenisnya
Sehari sekali kamu selesaiin problem yang susah 😅
setuju si, kalau begini kemungkinan besar cyclic
Bang, boleh kali bahas C# ?
Lg ambil matkul c# 😂? Wkwkwkwk
Kalo di riil industri pake .Net framework sekalian untuk bahasa c# nya
kiri MVC , kanan HMVC
bar bar aja lah full stack gausah pake driven driven kang