ข้ามไปยังเนื้อหาหลัก

การย้ายจาก v1 ไป v2

ทำไมถึงต้อง v2?​

แนวคิดดั้งเดิมของ Feature-Slices ถูกประกาศ ในปี 2018

ตั้งแต่นั้นมา มีการเปลี่ยนแปลงหลายอย่างใน Methodology แต่ในขณะเดียวกัน หลักการพื้นฐานยังคงเดิม:

  • การใช้โครงสร้าง Frontend project ที่ เป็นมาตรฐาน
  • การแบ่งแอปพลิเคชันโดยยึด Business logic เป็นหลัก
  • การใช้ Isolated Features เพื่อป้องกัน Implicit side effects และ Cyclic dependencies
  • การใช้ Public API พร้อมกับข้อห้ามในการปีน "เข้าไปข้างใน" ของ Module

ในขณะเดียวกัน ในเวอร์ชันก่อนหน้าของ Methodology ก็ยังมี จุดอ่อน ที่:

  • บางครั้งนำไปสู่ Boilerplate code
  • บางครั้งนำไปสู่ความซับซ้อนเกินจำเป็นของฐานโค้ดและกฎที่ไม่ชัดเจนระหว่าง Abstractions
  • บางครั้งนำไปสู่ Implicit architectural solutions ซึ่งขัดขวางการปรับปรุงโปรเจกต์และการ Onboarding คนใหม่

เวอร์ชันใหม่ของ Methodology (v2) ถูกออกแบบมา เพื่อกำจัดข้อบกพร่องเหล่านี้ ในขณะที่ยังคงข้อดีที่มีอยู่ ของแนวทางนี้ไว้

ตั้งแต่ปี 2018 ยังมีการพัฒนา อีก Methodology ที่คล้ายกัน - feature-driven ซึ่งถูกประกาศครั้งแรกโดย Oleg Isonen

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

ผลลัพธ์คือ สิ่งนี้ส่งผลกระทบแม้กระทั่งชื่อของ Methodology - "feature-sliced"

ทำไมถึงสมเหตุสมผลที่จะย้ายโปรเจกต์ไป v2?​

WIP: เวอร์ชันปัจจุบันของ Methodology อยู่ระหว่างการพัฒนาและรายละเอียดบางอย่าง อาจเปลี่ยนแปลงได้

🔍 Architecture ที่โปร่งใสและเรียบง่ายขึ้น​

Methodology (v2) นำเสนอ Abstractions ที่เข้าใจง่ายและเป็นสากลมากขึ้น รวมถึงวิธีแยก Logic ในหมู่นักพัฒนา

ทั้งหมดนี้ส่งผลดีอย่างมากต่อการดึงคนใหม่ๆ เข้ามาร่วมทีม รวมถึงการศึกษาโปรเจกต์ปัจจุบัน และการกระจาย Business logic ของแอปพลิเคชัน

📦 Modularity ที่ยืดหยุ่นและจริงใจมากขึ้น​

Methodology (v2) อนุญาตให้ กระจาย Logic ในวิธีที่ยืดหยุ่นมากขึ้น:

  • ด้วยความสามารถในการ Refactor ส่วนที่แยกจากกันได้ตั้งแต่ต้น
  • ด้วยความสามารถในการพึ่งพา Abstractions เดียวกัน โดยไม่ต้องมี Dependencies ที่พันกันยุ่งเหยิงโดยไม่จำเป็น
  • ด้วยข้อกำหนดที่ง่ายขึ้นสำหรับตำแหน่งของ Module ใหม่ (layer => slice => segment)

🚀 Specifications, Plans, Community ที่มากขึ้น​

ในขณะนี้ core-team กำลังทำงานอย่างแข็งขันในเวอร์ชันล่าสุด (v2) ของ Methodology

ดังนั้นสำหรับเวอร์ชันนี้:

  • จะมี Cases / Problems ที่ถูกอธิบายมากขึ้น
  • จะมี Guides ในการประยุกต์ใช้มากขึ้น
  • จะมีตัวอย่างจริงมากขึ้น
  • โดยรวมแล้ว จะมี Documentation มากขึ้นสำหรับการ Onboarding คนใหม่และการศึกษาแนวคิดของ Methodology
  • Toolkit จะถูกพัฒนาในอนาคตเพื่อให้สอดคล้องกับแนวคิดและข้อตกลงทาง Architecture

แน่นอนว่าจะมีการ Support ผู้ใช้สำหรับเวอร์ชันแรกด้วย - แต่เวอร์ชันล่าสุดยังคงเป็น Priority สำหรับเรา

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

Changelog​

BREAKING Layers​

ตอนนี้ Methodology กำหนดให้มีการจัดสรร Layers อย่างชัดเจนที่ Top level

  • /app > /processes > /pages > /features > /entities > /shared

  • นั่นคือ ไม่ใช่ทุกอย่างจะถูกปฏิบัติเหมือน Features/Pages อีกต่อไป

  • แนวทางนี้ช่วยให้คุณ กำหนดกฎสำหรับ Layers ได้อย่างชัดเจน:

  • ยิ่ง Layer อยู่สูง เท่าไหร่ Module ก็ยิ่งมี Context มากขึ้นเท่านั้น

    (พูดง่ายๆ คือแต่ละ Module ของ Layer - สามารถ Import ได้เฉพาะ Modules ของ Layers ที่อยู่ต่ำกว่า แต่ห้าม Import จาก Layer ที่สูงกว่า)

  • ยิ่ง Layer อยู่ต่ำ เท่าไหร่ ก็ยิ่ง อันตรายและรับผิดชอบสูง ในการเปลี่ยนแปลงมัน

    (เพราะมักจะเป็น Layers ล่างๆ ที่ถูกใช้งานซ้ำมากที่สุด)

BREAKING Shared​

Infrastructure abstractions /ui, /lib, /api ที่เคยอยู่ที่ src root ของโปรเจกต์ ตอนนี้ถูกแยกออกมาเป็น directory แยกต่างหาก /src/shared

  • shared/ui - ยังคงเป็น UI Kit ทั่วไปของแอปพลิเคชันเช่นเดิม (Optional)
    • ในขณะเดียวกัน ก็ไม่มีใครห้ามใช้ Atomic Design ที่นี่เหมือนเมื่อก่อน
  • shared/lib - ชุดของ Auxiliary libraries สำหรับ Implement logic
    • ยังคงเหมือนเดิม - ไม่ใช่ที่ทิ้ง Helpers มั่วซั่ว
  • shared/api - จุดเข้าถึงร่วมสำหรับ API
    • สามารถ Register แบบ Local ในแต่ละ Feature / Page ได้ด้วย - แต่ไม่แนะนำ
  • เหมือนเดิม - ไม่ควรมีการผูกมัดอย่างชัดเจนกับ Business logic ใน shared
    • ถ้าจำเป็น คุณต้องย้ายความสัมพันธ์นี้ไปที่ระดับ entities หรือสูงกว่า

NEW Entities, Processes​

ใน v2 , มี Abstractions ใหม่ เพิ่มเข้ามาเพื่อกำจัดปัญหาความซับซ้อนของ Logic และ High coupling

  • /entities - Layer Business entities ที่ประกอบด้วย Slices ที่เกี่ยวข้องโดยตรงกับ Business models หรือ Synthetic entities ที่ต้องใช้แค่ใน Frontend
    • ตัวอย่าง: user, i18n, order, blog
  • /processes - Layer Business processes ที่แทรกซึมทั่วทั้ง App
    • Layer นี้เป็น Optional มักจะแนะนำให้ใช้เมื่อ Logic เติบโตขึ้นและเริ่มกระจายไปในหลายๆ หน้า
    • ตัวอย่าง: payment, auth, quick-tour

BREAKING Abstractions & Naming​

ตอนนี้ Abstractions เฉพาะและ คำแนะนำที่ชัดเจนสำหรับการตั้งชื่อ ถูกกำหนดขึ้นแล้ว

Layers​

  • /app — Application initialization layer
    • เวอร์ชันก่อนหน้า: app, core,init, src/index (ก็มีเหมือนกัน)
  • /processes — Business process layer
    • เวอร์ชันก่อนหน้า: processes, flows, workflows
  • /pages — Application page layer
    • เวอร์ชันก่อนหน้า: pages, screens, views, layouts, components, containers
  • /features — Functionality parts layer
    • เวอร์ชันก่อนหน้า: features, components, containers
  • /entities — Business entity layer
    • เวอร์ชันก่อนหน้า: entities, models, shared
  • /shared — Layer of reused infrastructure code 🔥
    • เวอร์ชันก่อนหน้า: shared, common, lib

Segments​

  • /ui — UI segment 🔥
    • เวอร์ชันก่อนหน้า: ui, components, view
  • /model — BL-segment 🔥
    • เวอร์ชันก่อนหน้า: model, store, state, services, controller
  • /lib — Segment of auxiliary code
    • เวอร์ชันก่อนหน้า: lib, libs, utils, helpers
  • /api — API segment
    • เวอร์ชันก่อนหน้า: api, service, requests, queries
  • /config — Application configuration segment
    • เวอร์ชันก่อนหน้า: config, env, get-env

REFINED Low coupling​

ตอนนี้มันง่ายขึ้นมากที่จะ ปฏิบัติตามหลักการ Low coupling ระหว่าง Modules ต้องขอบคุณ Layers ใหม่

ในขณะเดียวกัน ก็ยังแนะนำให้หลีกเลี่ยงกรณีที่ยากต่อการ "Uncouple" Modules ให้มากที่สุดเท่าที่จะเป็นไปได้

ดูเพิ่มเติม​