ข้ามไปยังเนื้อหา
อัตลักษณ์เดียวที่คงที่ มนุษย์เป็นผู้จัดทำโดยค่าเริ่มต้น ออกแบบให้พกพาได้
Topoloom by Relia1

การจัดทำองค์ความรู้ร่วมกันการสร้างโมเดลระบบ

ออบเจ็กต์เดียวในทุกจุดที่มีความสำคัญ

Service หนึ่งรายการอาจปรากฏในเอกสารและไดอะแกรมหลายแห่ง อ้างอิงออบเจ็กต์ร่วมหนึ่งรายการ แล้วตรวจผลของการเปลี่ยนเจ้าของหรือความสัมพันธ์การพึ่งพา

เขียนอย่างเป็นธรรมชาติสร้างโมเดลอย่างแม่นยำเชื่อมโยงความรู้ไว้ตลอด

Document Graphเวอร์ชัน artifact · เผยแพร่ v8
ออบเจ็กต์ที่ใช้ซ้ำได้svc.payment
Payment Service

Service ที่ประกาศแล้ว · ออบเจ็กต์สถานะ Active

  1. 01 · ข้อความภาพรวมสถาปัตยกรรมส่งคำขอที่ได้รับอนุญาตผ่าน Payment Service
  2. 02 · ไดอะแกรมCheckout APIDEPENDS_ON → svc.payment
  3. 03 · Runbookการกู้คืนระบบชำระเงินsvc.payment — HAS_RUNBOOK → การกู้คืนระบบชำระเงิน
  4. 04 · SLOเป้าหมายของการชำระเงินsvc.payment — HAS_SLO → เป้าหมายของการชำระเงิน
  5. 05 · การตรวจทานการเปลี่ยนแปลงเชิงความหมายเปลี่ยนเจ้าของ · v7 → v8
วงจรความรู้ที่เชื่อมโยงกัน

อัตลักษณ์ที่คงที่ออบเจ็กต์เดียวอ้างอิงร่วมกันในข้อความ ไดอะแกรม และงานปฏิบัติการ

ความสัมพันธ์ที่ชัดเจนการเชื่อมต่อที่มีชนิดทุกลิงก์ที่ประกาศจะอธิบายว่าการเชื่อมต่อนั้นหมายถึงอะไร

การเปลี่ยนแปลงที่ตรวจทานได้มองเห็นผลกระทบการเปลี่ยนแปลงเชิงความหมายได้รับการตรวจทานก่อนเผยแพร่

ภายใน Topoloom

เริ่มจากเอกสาร แล้วเชื่อมโยงความหมายไว้ด้วยกัน

ภาพนี้แสดงข้อความที่ร่วมกันจัดทำและบันทึกแล้ว พร้อมความสัมพันธ์ของ Payment Service ที่ประกาศไว้ ทดสอบการใช้ออบเจ็กต์ซ้ำและการตรวจทานเชิงความหมายในการประเมินที่กำหนดขอบเขตได้

Payment Service Overview ในสถานะ Saved มีผู้แก้ไขอื่นหนึ่งคน ความสัมพันธ์ที่ประกาศแล้ว และเคอร์เซอร์ของ Alex Morgan
เอกสารถูกบันทึกแล้ว ความสัมพันธ์ที่ประกาศของ Payment Service แสดงคู่กับข้อความที่อ่านได้ ขณะที่ Alex Morgan กำลังแก้ไขเอกสารเดียวกัน ส่วนติดต่อผู้ใช้ของผลิตภัณฑ์แสดงเป็นภาษาอังกฤษดูรายละเอียดภาพ

ปัญหาด้านการประสานงาน

ความรู้กระจัดกระจาย ตรงจุดที่ระบบเชื่อมต่อกัน

คำอธิบาย Service ไดอะแกรม Runbook และข้อมูลเจ้าของค่อย ๆ แยกเป็นสำเนาที่เป็นอิสระต่อกัน แม้ยังดูเหมือนเกี่ยวข้องกัน แต่ไม่มีสิ่งใดเชื่อมโยงกันเลย ไม่มีอัตลักษณ์ร่วม ไม่มีบันทึกว่าข้อความแต่ละข้อมาจากไหน และไม่มีการตรวจทานร่วมกัน

เนื้อหาเดียวกันอาจป้อนให้การค้นหา การตรวจทานโดยคน และระบบ AI ได้ ผู้อ่านแต่ละคนต้องรู้ว่าใครเป็นผู้ประกาศข้อเท็จจริง ข้อเท็จจริงนั้นอยู่ในเวอร์ชันใด และตนอ่านอะไรได้บ้าง

แนวทางของ Topoloom

เขียนได้อย่างเป็นธรรมชาติ แม่นยำเมื่อจำเป็น

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

01

ทำงานในเอกสารที่อ่านง่าย

อธิบายระบบในเอกสารและไดอะแกรมที่ทำงานร่วมกัน ก่อนทำให้ส่วนสำคัญเป็นโครงสร้างอย่างเป็นทางการ

เอกสาร · บล็อก · การทำงานร่วมกัน
02

ยกระดับแนวคิดสำคัญ

เปลี่ยนแนวคิดที่เลือกเป็นออบเจ็กต์ที่ใช้ซ้ำได้ และกำหนดความหมายของความสัมพันธ์อย่างชัดเจน

ออบเจ็กต์ · ชนิด · ความสัมพันธ์
03

ใช้อัตลักษณ์เดียวที่คงที่ซ้ำ

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

การอ้างอิง · เวอร์ชัน · การตรวจทาน

วงจรความรู้ที่เชื่อมโยงกัน

Service เดียวเวิร์กโฟลว์ที่เชื่อมโยงกัน

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

Architecture / CheckoutSemantic model · v8
ภาพรวมสถาปัตยกรรมประกาศแล้ว

Checkout ส่งคำขอที่ได้รับอนุญาตผ่าน Payment Service

บล็อก 14 · มนุษย์เป็นผู้จัดทำ
ไดอะแกรมระบบขอบที่ประกาศแล้ว
Checkout APIDEPENDS_ON →svc.payment
โหนดที่มีชนิด · การอ้างอิงที่คงที่
Runbookออบเจ็กต์ที่เชื่อมโยงแล้ว

การกู้คืนระบบชำระเงิน

svc.payment — HAS_RUNBOOK →
SLOออบเจ็กต์ที่เชื่อมโยงแล้ว

เป้าหมายของการชำระเงิน

svc.payment — HAS_SLO →
การตรวจทานเชิงความหมายv7 → v8

Core PlatformPayments Team

เปลี่ยนเจ้าของ · กระทบ 3 การอ้างอิง
ออบเจ็กต์ที่ใช้ซ้ำได้svc.payment
Payment Service

Service ที่ประกาศแล้ว · ออบเจ็กต์สถานะ Active

01ข้อความ

เส้นแบ่งความน่าเชื่อถือที่มองเห็นได้

ประกาศที่นี่ ยืนยันที่อื่น

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

สำรวจการออกแบบเพื่อความน่าเชื่อถือ

สำหรับผู้นำด้านเทคนิค

เปลี่ยนงานเอกสารให้เป็น ผลลัพธ์ที่วัดได้

เริ่มจาก Service หนึ่งรายการและบันทึกว่าทีมจัดการการอัปเดตอย่างไรในวันนี้ หลังการประเมินแบบกำหนดขอบเขต ให้เปรียบเทียบการดูแล การตรวจทาน ความครอบคลุม และการส่งออก

01 / ภาระการดูแล

วัดการแก้ไขซ้ำ

นับจุดที่ต้องอัปเดตในปัจจุบัน แล้วนับว่าการอ้างอิงใดใช้ออบเจ็กต์เดียวกัน และสำเนาใดยังต้องแก้ด้วยมือ

02 / เวลาตรวจทาน

วัดเวลาจนถึงการตรวจทานที่มีข้อมูลครบ

เปรียบเทียบเวลาที่ผู้ตรวจทานต้องใช้เพื่อเข้าใจการเปลี่ยนเจ้าของ ความสัมพันธ์การพึ่งพา SLO หรือ Decision

03 / ความครอบคลุมของความรู้

ตรวจช่องว่างด้านเจ้าของและความรู้ปฏิบัติการ

นับ Service ที่มีเจ้าของระบุไว้ Runbook ที่เชื่อมโยง SLO และบริบทการพึ่งพาที่ชัดเจน

04 / ขอบเขตการส่งออก

ตรวจเส้นทางการนำข้อมูลออก

เปิดแพ็กเกจนอก Topoloom แล้วตรวจเนื้อหาที่อ่านได้ ID ที่คงที่ เวอร์ชัน ความสัมพันธ์ ที่มา บันทึกการตรวจทาน และการแมปสิทธิ์ อ่านรายงานส่วนที่ละไว้ การปกปิด และการแมปใหม่

ดูวงจรความรู้ที่เชื่อมโยงกัน

นำ Service มาหนึ่งรายการ
กำหนดขอบเขตการสาธิตทางเทคนิค

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

ขอรับเดโม สำรวจแพลตฟอร์ม

ภาพหน้าจอผลิตภัณฑ์