ใช้แพ็คเกจ (อัญมณีไข่ ฯลฯ ) เพื่อสร้างสถาปัตยกรรมที่แยกออก

ประเด็นหลัก

เห็นการสนับสนุนที่ดีมากที่สุดแพลตฟอร์มการเขียนโปรแกรมที่ทันสมัยมีการบริหารจัดการแพคเกจ (คิดว่าgem, npm, pipฯลฯ ) ไม่ได้ทำให้ความรู้สึกในการออกแบบโปรแกรมหรือระบบจะประกอบด้วยแพคเกจการพัฒนาภายในเพื่อส่งเสริมและสร้างสถาปัตยกรรมคู่หลวม?

ตัวอย่าง

ตัวอย่างนี้จะสร้างแพคเกจสำหรับการเข้าถึงฐานข้อมูลรวมถึงการตรวจสอบและส่วนประกอบอื่น ๆ ของระบบ แน่นอนว่าใช้แพ็คเกจภายนอกด้วย จากนั้นระบบของคุณจะนำเข้าและใช้แพ็คเกจเหล่านี้แทนที่จะรวมรหัสไว้ในฐานรหัสของตนเอง

การพิจารณา

สำหรับฉันดูเหมือนว่าสิ่งนี้จะส่งเสริมการแยกรหัสและช่วยให้สามารถบำรุงรักษาได้เกือบจะเป็นแอพพลิเคชั่นบนเว็บเทียบกับเดสก์ท็อป (มีการใช้งานการอัปเดตเกือบอัตโนมัติโดยใช้ฐานรหัสเดียวสำหรับการใช้งานเดียว

ดูเหมือนว่าแนวคิดการออกแบบที่สมเหตุสมผลและมีเหตุผลหรือไม่ สิ่งนี้ใช้จริง ๆ แล้วเป็นวิธีมาตรฐานในการสร้างแอพพลิเคชั่นในปัจจุบันหรือไม่?

ฉันมีส่วนร่วมในโครงการเช่นนี้สองครั้งแล้ว (ทั้งใช้ nuget กับ. NET) และฉันจะบอกว่าในเรื่องความสมดุลมันเป็นความคิดที่ดี แต่ระยะทางของคุณอาจแตกต่างกันไป

อย่าคิดว่าเป็นยาครอบจักรวาลที่จะแก้ปัญหาทั้งหมดของคุณโดยไม่ก่อให้เกิดปัญหาใหม่ การจัดการการปล่อยจะได้รับความซับซ้อนของเลเยอร์ใหม่ทั้งหมดคุณจะต้องจัดการกับปัญหาการพึ่งพาเวอร์ชันที่คุณไม่เคยรู้มาก่อนและคุณจะมีเวลาเมื่อคุณสาปแช่งการตัดสินใจเพราะคุณต้องอัพเกรดแพ็กเกจที่แตกต่างกันสี่อัน ข้อผิดพลาดเล็ก ๆ ที่คุณต้องแก้ไขและปล่อยอย่างรวดเร็ว

ในอีกทางหนึ่งคุณพูดถูกว่า decouples หลายอย่าง คุณจะพบโอกาสมากขึ้นเมื่อคุณคิดว่า "โอ้ที่ได้ผลออกมาดีกว่า" ถ้าคุณทำมากจนเกินไป หากคุณมีรหัสที่ใช้ร่วมกันระหว่างแอปพลิเคชั่นหลายตัวมันจะมีประสิทธิภาพเป็นพิเศษเพราะคุณสามารถอัพเกรดแอพได้อย่างอิสระ

และหากคุณเป็นเหมือนฉันคุณจะเริ่มเขียนแอปทดสอบที่ใช้แพ็คเกจของคุณอย่างรวดเร็วเพื่อลบแอปพลิเคชันเลเยอร์ทั้งหมดออกจากกระบวนการค้นหาข้อผิดพลาดของคุณ และในตัวของมันเองอาจจะคุ้มค่ากว่า

นี่เป็นความคิดที่ดีโดยรวม คุณจะต้องคิดเกี่ยวกับการตั้งค่าพื้นที่เก็บข้อมูลแพคเกจภายใน (มักเรียกว่า "คลังเก็บสิ่งประดิษฐ์" ในโลก Java หรือ "เซิร์ฟเวอร์ pypi" ในโลก Python) เพื่อให้คุณมีแพคเกจเหล่านั้นที่คุณไม่ต้องการหรือสามารถ ' ไม่ปล่อยเป็นโอเพ่นซอร์ส

ตามที่ @pdr ได้บันทึกไว้ให้เตรียมพร้อมสำหรับนรกของคุณเองโดยที่การเปลี่ยนแปลงบางแพ็กเกจจำเป็นต้องมีการเปลี่ยนแปลงครั้งแรกในแพ็คเกจอื่นและนี่หมายถึงไม่เพียงแค่เปลี่ยนบรรทัดของโค้ด แต่เป็นการทดสอบซึ่งอาจเป็นที่ยอมรับการเปลี่ยนแปลง การสร้างรีลีสและการอัพโหลดรีลีสไปยังที่เก็บแพ็กเกจข้างต้น แล้วเปลี่ยนสิ่งที่คุณตั้งใจจะเปลี่ยนแปลง

สูตรเดียวที่ฉันสามารถให้คุณจากประสบการณ์ของผมที่จะลองและลดการนี้ไม่ต้องพึ่งพา แต่เพียงผู้เดียวในการสรุปแนวคิดร่วมกันจากแพคเกจของคุณให้เป็น "คนธรรมดา" หรือ "กรอบ" แพคเกจ สิ่งนี้อาจดูเหมือนเป็นสิ่งที่ต้องทำ แต่จะนำไปสู่แพ็คเกจสัตว์ประหลาดที่ต้องการการเปลี่ยนแปลงและเผยแพร่บ่อยครั้ง ดีกว่ามากคิดเกี่ยวกับฟังก์ชันในระบบของคุณและสร้างแพ็คเกจผู้ช่วยสำหรับแต่ละรายการดังที่คุณได้ระบุไว้ในคำถามของคุณ

นอกจากนั้นประโยชน์หลักที่คุณจะได้รับคือแอปของคุณได้รับการปกป้องจากการพึ่งพา (หลาย ๆ คน) เพื่อให้คุณสามารถแลกเปลี่ยนได้โดยไม่ต้องเจ็บปวด