Struktur Folder Aplikasi Harusnya Kayak Gini | PZN Reaction

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...
KZbin : / programmerzamannow

[@MrKeliv]

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

[@RakaRasell]

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.

[@DioArsya]

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 🎉🎉🎉

[@DaniSetiawan-ju5pn]

baru mau komen gini juga, simplenya MVC dan HMVC.

[@muhammadmasum2753]

yak betul HMVC sistem modular wrapping mvc

[@MrSundaayy]

Menit pertama yg saya bayangin ya seperti gambar di behind the scene itu 😂 di masing-masing modul/domain ya bakal ada mvc nya juga

[@ihsannuruliman4005]

Basically layered architecture vs vertical slicing architecture. Selalu ada plus minusnya walau yg kanan sekarang lagi populer.

[@enkaperson]

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.

[@afterschool2594]

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

[@m1dway]

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

[@seigaish]

Mw kiri atau yg kanan bebas aja, yg penting sih ada unit test nya, terlebih utk yg bisnis proses utamanya dibuat test case. 😊

[@NandaWidyatama]

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

[@tirtaadi2430]

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.

[@RochafiAlvin]

Cakep, selalu suka sama bahasan selain language dan framework seperti ini. Terimakasih banyak Pak

[@soktahu2459]

07:16 Jadiin materi terpisah mas Eko, untuk menghindari cyclic dependency antar module nya. Lagi mengalaminya nih 😆

[@Rendyariawindana]

iya intinya modular tiap modularnya ada mvc dan api nya dll saya sdh seperti itu dari dulu sampe skr

[@syifaprasetyo3138]

menarik nih. request bahas monorepo juga pak 🙏

[@didi_abdillah]

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.

[@MariniSukamto]

Saya belum ngerti masalah ini. Tapi aku mau tanya, framework Django termasuk yang mana menurut pembahasan ini?

[@andikasaputra1390]

pernah coba pakai feature driven, nah dependency nya itu yg bikin pusing. beberapa bahasa pemrograman tidak memperbolehkan itu

[@faizalrifaldy]

saya 2021 pernah kerja sama ama orang ukrain buat bikin fitur di server game, jadi moduler nya itu berdasarkan nama fiturnya

[@fajaramaulana]

10:18 itu kaya HMVC ya, saya kurang lebih kaya gitu soalnya 😁

[@fakeITDevTeam]

jadi inget pas develop desktop app. iya kan?

[@theshadowofberak9117]

sama aja isi nya MVC juga tiap feature

[@muhammadmasruri7230]

Ikut tanya bang, klo yg Feature-driven itu contohnya kaya Django bukan bang?

[@RidwanGhibran]

Bang, boleh kali bahas C# ?

[@VersiPertama]

Lg ambil matkul c# 😂? Wkwkwkwk Kalo di riil industri pake .Net framework sekalian untuk bahasa c# nya

[@fajarislami2515]

setuju si, kalau begini kemungkinan besar cyclic

[@pasarbunul4149]

Salah satu kelemahan software engineering adalah miskin empirical evidence, hampir semua hanya didasari gut feelings.

[@friedec3622]

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.

[@pasarbunul4149]

@@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.

[@gilangprambudi354]

​@@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.

[@aisimo]

Lah kantor2 yg saya pegang masih pake sql server 2008 😅

[@truthseekers5609]

@@gilangprambudi354 nah bener... sederhananya lebih mentingin keindahannya aja ketimbang fungsionalnya...

[@alfi7135]

Bahasa pemrograman seperti Go bisa mendeteksi adanya circular dependency. Akibatnya? Program tidak bisa dijalankan/di-build.

[@xmazlan]

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.

[@hendritriwanto2714]

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

[@akbarhday]

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

[@bimajatmikoabadi5706]

Kalau dibuat feature driven, gimana implementasi sharing module atau function yang reusable?

[@RezaElborneo]

tapi mau se modular apapun di layer app nya.. tetap aja di database nya high coupling kalo masih monolith. 😭

[@pocketprime]

apakah bisa disimpulkan "nge-monolith-in microservice"? :)

[@vaporizel]

kalo strukturnya featured driven trus naro cron sama config file dimana? payment procesor ada cron, support center ada cron, mencar2 jadinya

[@ipunkk3578]

Request ulang bahas encryption at rest dong 😁

[@ikhwanzain]

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

[@desrucca]

Bener bgt, ini yg selalu sy pikirin. Bakal pusing ngatur dependencynya kalo struktur foldernya berdasarkan domain

[@DhieIra]

udah dari dulu pakai feature driven. lebih nyaman aja 😀

[@juvan.nayoan]

tergantung project kebutuhannya gimana dan seberapa besar projectnya, kalo small medium tech driver masih sangat ok, feature driven lebih cocok kalau untuk di frontend

[@bin8019]

Mau pake yang manapun, yang penting aplikasinya jalan 😊

[@yanz_77]

kalau pake framework macam laravel apa ga kerepotan tuh ngerename folder satu2?

[@VersiPertama]

Sesuaikan sama kebutuhan saja, ga saklek harus diikuti

[@suryaelz]

mantap om, sering seringin aja bikin konten kek gini wkwk

[@bagusjatikusuma]

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.

[@ikhsansatriadi7346]

Saya di backend pake layer first / tech driven, sedangkan disisi frontend pake feature driven.

[@internetclan6350]

kalau kejar tayang, jdi feature driven wkwkwkk

[@azwarbuton]

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.

[@KadekRegen]

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.

[@visual-bagi]

ini sih HMVC

[@dimasputraari]

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

[@MrGbison]

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..

[@virtuaza]

Kalo aplikasinya monolith cocok sih, tapi kalo aplikasinya dipecah2 ke banyak project misal untuk microservices, 1 module 1 project lebih cocok tech driven.

[@dev9033]

mungkin lebih tepatnya, satu prefix API (kalau backend) satu folder, kemudian ada folder lib dan folder helper terpisah

[@m1dway]

Di sini pentingnya domain discovery sebelon membuat software. Jdi masalah2 di feature driven lbh mudah diatasi di depan

[@agungiswanto25]

misal pake express generator gimana bang soalnya kan express itu setau saya mengusung unopinionated framework

[@danielprast]

Klo topic seperti ini apakah termasuk area disiplin ilmu software architect bukan? 🙂

[@ilmu_web]

Setuju, menarik bahasannya, memang dengan struktur folder yang baik di aplikasi menjadi penting dalam pengembangan kedepan

[@khoerulumam8316]

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

[@faktapijar]

django by default udah per fitur pembagian foldernya

[@izumiosana]

Feature Driven juga di dalam tiap foldernya kan filenya dipisah pakai Tech Driven.

[@wahyono1739]

djanggo itu pakai yg 1 nya itu,, tiap domain ada 1 folder dan subfoder, tp pemahaman juga agak susah menurutku..

[@bo_leang]

case kayak diatas bukannya lebih cocok pake monorepo ya ?

[@mochamadaufa7079]

Ini yang kutunggu tunggu

[@mochamadaufa7079]

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

[@singgihputrapratama]

Anggap saja dibagi per fitur. misal payment, user, atau mungkin streaming. dari 3 feature tersebut biasanya menggunakan beberapa table.

[@MbahStinky]

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

[@soktahu2459]

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.

[@loremipsumamet2477]

Enakan yg tech driven strukturnya mudah di pelajari, apalagi buat saya yg pemula hehe ✌

[@anbiabohlam5468]

tapi bakal jadi lompat sana lompat sini pas nge develop fitur baru

[@havefun9380]

bang eko, ada tips biar skill problem solving terasah?

[@Bakas_posai]

Main main ke hacker rank atau sejenisnya

[@Kanookoochn]

Sehari sekali kamu selesaiin problem yang susah 😅

[@djamaatul]

kiri MVC , kanan HMVC

[@geraldsihotang]

[@bahyusanciko]

bar bar aja lah full stack gausah pake driven driven kang