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 🎉🎉🎉
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
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.
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.
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
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.
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
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.
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
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
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
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.
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
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..
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 saya sih setuju menggabungkan keduanya... Terutama untuk project besar yang monolith. Kalau di CodeIgniter yang basisnya MVC, bisa pakai addon HMVC untuk base frameworknya
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.
Kalo aplikasinya monolith cocok sih, tapi kalo aplikasinya dipecah2 ke banyak project misal untuk microservices, 1 module 1 project lebih cocok tech driven.
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.
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
