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

9 ай бұрын

baru mau komen gini juga, simplenya MVC dan HMVC.

@muhammadmasum2753

9 ай бұрын

yak betul HMVC sistem modular wrapping mvc

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.

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

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

@friedec3622

9 ай бұрын

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

9 ай бұрын

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

9 ай бұрын

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

9 ай бұрын

Lah kantor2 yg saya pegang masih pake sql server 2008 😅

@truthseekers5609

9 ай бұрын

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

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

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

mantap om, sering seringin aja bikin konten kek gini wkwk

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

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.

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

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

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

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

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

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

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

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.

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

menarik nih. request bahas monorepo juga pak 🙏

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

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

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.

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.

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

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.

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

udah dari dulu pakai feature driven. lebih nyaman aja 😀

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

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

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

Ini yang kutunggu tunggu

Request ulang bahas encryption at rest dong 😁

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

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

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.

Kalo aplikasinya monolith cocok sih, tapi kalo aplikasinya dipecah2 ke banyak project misal untuk microservices, 1 module 1 project lebih cocok tech 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..

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

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

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

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

8 ай бұрын

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

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

@anbiabohlam5468

9 ай бұрын

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

kalau kejar tayang, jdi feature driven wkwkwkk

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

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

case kayak diatas bukannya lebih cocok pake monorepo ya ?

jadi inget pas develop desktop app. iya kan?

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.

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

9 ай бұрын

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.

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

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

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

django by default udah per fitur pembagian foldernya

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

Mau pake yang manapun, yang penting aplikasinya jalan 😊

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

@VersiPertama

9 ай бұрын

Sesuaikan sama kebutuhan saja, ga saklek harus diikuti

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

8 ай бұрын

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

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

sama aja isi nya MVC juga tiap feature

Bang, boleh kali bahas C# ?

@VersiPertama

9 ай бұрын

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

bang eko, ada tips biar skill problem solving terasah?

@Bakas_posai

9 ай бұрын

Main main ke hacker rank atau sejenisnya

@Kanookoochn

9 ай бұрын

Sehari sekali kamu selesaiin problem yang susah 😅

ini sih HMVC

setuju si, kalau begini kemungkinan besar cyclic

kiri MVC , kanan HMVC

bar bar aja lah full stack gausah pake driven driven kang