สถาปัตยกรรมอ้างอิงระบบการดำเนินงานด้านโลจิสติกส์

เอกสารอ้างอิงแอปพลิเคชัน นี่คือสถาปัตยกรรมเชิงตัวอย่างและรายการตรวจสอบขอบเขตงาน ไม่ใช่โครงการลูกค้าที่ผ่านการตรวจสอบหรือการใช้งานจริงที่มีการวัดผล เทคโนโลยี ขอบเขตการผสานระบบ และรายการส่งมอบจะตกลงกันตามบรีฟจริง

สถานการณ์และข้อจำกัด

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

สถาปัตยกรรม

เลเยอร์และความรับผิดชอบ

เลเยอร์	เทคโนโลยี	รับผิดชอบเรื่องใด
เว็บปฏิบัติการ	Vue 3 + Element Plus	รับคำสั่งซื้อ กระดานจัดส่ง การจัดการข้อยกเว้น และการตรวจสอบการเรียกเก็บเงิน
แอปพนักงานขับรถ	Android (Kotlin) รองรับการทำงานออฟไลน์	รายการงาน การสแกน รูปถ่าย ลายเซ็น และการบันทึกสถานะ ทุกอย่างจะเขียนลงเครื่องก่อนและอัปโหลดเมื่อมีการเชื่อมต่อ
พอร์ทัลลูกค้า	โปรแกรมมินิ WeChat	ติดตามด้วยตนเอง วัดการเปลี่ยนแปลงของปริมาณคำถามหรือคำขอข้อมูล แทนการสมมติว่าปริมาณจะลดลง
API	Go + Gin	การตรวจสอบความถูกต้อง กฎการจัดส่ง การรับเหตุการณ์ และการคำนวณค่าบริการ
พื้นที่จัดเก็บ	MySQL	รายการฝากส่ง เหตุการณ์ และการชำระบัญชี ตารางเหตุการณ์เป็นแบบเพิ่มอย่างเดียวและเป็นแหล่งข้อมูลหลักของระบบ
แคช / คิว	Redis	การแคชกระดานจัดส่ง การขจัดข้อมูลอัปโหลดซ้ำ และงานเบื้องหลังสำหรับการเรียกเก็บเงินและการแจ้งเตือน
ไฟล์	พื้นที่จัดเก็บออบเจ็กต์	รูปถ่ายและลายเซ็นเพื่อเป็นหลักฐานการส่งมอบ โดยอ้างอิงด้วยคีย์แทนการจัดเก็บไว้ในฐานข้อมูล

แบบจำลองข้อมูล

ตารางด้านล่างประกอบด้วยกฎที่ทุกส่วนอื่นต้องพึ่งพา หากกำหนดสิ่งเหล่านี้ผิด สิ่งที่ได้จะเปลี่ยนจากเดโมที่ใช้งานได้เป็นระบบที่ไม่สามารถขยายต่อได้

เอนทิตีหลัก

เอนทิตี	ฟิลด์หลัก ความสัมพันธ์ และกฎ
consignment	ระเบียนการจัดส่ง: คู่สัญญา ที่อยู่ ประเภทบริการ ช่วงเวลา น้ำหนักและปริมาตรที่แจ้งไว้ และเกณฑ์การกำหนดราคาที่ตกลงกันเมื่อรับงาน
shipment_event	เป็นแบบเพิ่มอย่างเดียว มีการประทับเวลา พร้อมผู้ปฏิบัติงาน สถานที่ ประเภทเหตุการณ์ และข้อมูลเหตุการณ์ สถานะปัจจุบันได้มาจากเหตุการณ์ล่าสุด ไม่ได้จัดเก็บแยกต่างหาก ซึ่งทำให้ลำดับเหตุการณ์สามารถชี้แจงได้ในการโต้แย้ง
task / assignment	การมอบหมายพนักงานขับรถและยานพาหนะพร้อมลำดับจุดแวะ รวมถึงประวัติการมอบหมายใหม่เมื่อมีการส่งต่องาน
pod_asset	หลักฐานการส่งมอบ: คีย์รูปถ่ายและลายเซ็น เวลาที่บันทึก และตำแหน่งของอุปกรณ์ ซึ่งเก็บไว้เป็นหลักฐานประกอบการเรียกเก็บเงิน
charge / invoice	รายการค่าบริการที่สร้างจากกฎบนเหตุการณ์ที่บันทึกไว้ โดยแต่ละรายการจะมีรหัสเหตุการณ์ที่ใช้เป็นเหตุผลรองรับ รายการในใบแจ้งหนี้ที่ไม่มีเหตุการณ์ที่ตรวจสอบย้อนกลับได้จะถูกปฏิเสธตามการออกแบบ
rate_card	กฎการกำหนดราคาเฉพาะลูกค้าตามน้ำหนัก ปริมาตร ระยะทาง เวลารอ และค่าธรรมเนียมเพิ่มเติม โดยมีการกำหนดเวอร์ชันเพื่อให้ใบแจ้งหนี้ย้อนหลังยังคงสร้างยอดเดิมได้

ส่วนติดต่อหลัก

ปลายทางที่รองรับกฎทางธุรกิจ

ปลายทาง	วัตถุประสงค์และข้อสังเกตด้านการทำงานพร้อมกัน
POST /api/v1/consignments	รับคำสั่งซื้อพร้อมการระบุพิกัดที่อยู่และการเลือกใช้เรตราคาในเวลาสร้างรายการ เพื่อให้เกณฑ์การกำหนดราคาถูกกำหนดไว้ก่อนเริ่มงาน
POST /api/v1/events/batch	อัปโหลดเหตุการณ์แบบกลุ่มจากแอปพนักงานขับรถหลังขาดการเชื่อมต่อ ขจัดข้อมูลซ้ำด้วย UUID เหตุการณ์จากไคลเอนต์ และจัดเก็บเวลาที่บันทึกแยกจากเวลาที่รับข้อมูล เพื่อให้ลำดับเหตุการณ์ยังคงตรงตามความเป็นจริง
POST /api/v1/tasks/{id}/pod	อัปโหลดลายเซ็นและรูปถ่ายพร้อมเวลาที่บันทึก โดยส่งคืนคีย์พื้นที่จัดเก็บที่เชื่อมโยงกับรายการฝากส่ง
POST /api/v1/billing/run	สร้างรายการค่าบริการจากเหตุการณ์สำหรับช่วงเวลาหนึ่ง ทำงานแบบไอดีมโพเทนต์ต่อ (ลูกค้า, ช่วงเวลา) เพื่อให้การเรียกใช้งานซ้ำแก้ไขผลลัพธ์แทนการสร้างรายการซ้ำ
GET /api/v1/track/{no}	การติดตามสาธารณะ โดยมีการแคชและเปิดเผยเฉพาะส่วนของเหตุการณ์ที่ลูกค้ามองเห็น

การตัดสินใจด้านเทคนิค

ใช้เหตุการณ์เป็นแหล่งข้อมูลหลัก และใช้สถานะเป็นค่าที่คำนวณได้ คอลัมน์สถานะที่แก้ไขได้จะสูญเสียประวัติที่จำเป็นต่อการจัดการข้อโต้แย้ง การคำนวณสถานะทำให้ต้องเชื่อมข้อมูลเพิ่ม แต่ได้บันทึกตรวจสอบที่ครบถ้วนและสามารถชี้แจงได้
จัดเก็บเวลาที่บันทึกและเวลาที่รับข้อมูลแยกกัน การสแกนของพนักงานขับรถเวลา 14:02 ที่อัปโหลดเวลา 17:30 ต้องแสดงเป็น 14:02 พร้อมระบุความล่าช้าในการอัปโหลด มิฉะนั้นทุกพื้นที่ออฟไลน์จะสร้างลำดับเวลาที่ไม่ถูกต้อง
UUID เหตุการณ์ที่สร้างโดยไคลเอนต์ การอัปโหลดซ้ำเป็นเรื่องปกติเมื่อการเชื่อมต่อไม่ดี ดังนั้นการขจัดข้อมูลซ้ำต้องใช้ตัวระบุที่ไคลเอนต์เป็นผู้ควบคุม
กำหนดเวอร์ชันให้เรตราคาแทนการแก้ไข การเปลี่ยนราคาต้องไม่เขียนทับใบแจ้งหนี้ของเดือนที่แล้วโดยไม่แจ้งให้ทราบ ดังนั้นเวอร์ชันเก่าจะยังคงอยู่ และค่าบริการย้อนหลังยังคงชี้ไปยังเวอร์ชันดังกล่าว
สร้างการเรียกเก็บเงินแต่ไม่ออกใบแจ้งหนี้โดยอัตโนมัติ กฎครอบคลุมกรณีที่คำนวณได้ ส่วนสิ่งที่ต้องใช้ดุลยพินิจของมนุษย์จะเข้าสู่คิวตรวจสอบแทนการบังคับให้เป็นระบบอัตโนมัติ

เป้าหมายการออกแบบเชิงสมมติ

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

เป้าหมายด้านความจุและประสิทธิภาพ

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

สิ่งที่รวมอยู่ในการส่งมอบ

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

การวางแผนสำหรับธุรกิจของคุณ

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