# Feature-Sliced Design


## th

- [ตัวอย่าง (Examples)](/examples.md): รายการเว็บไซต์ที่สร้างด้วย Feature-Sliced Design
- [🧭 การนำทาง (Navigation)](/nav.md): Feature-Sliced Design Navigation help page
- [เวอร์ชันของ Feature-Sliced Design](/versions.md): Feature-Sliced Design Versions page listing all documented site versions
- [💫 Community](/community.md): Community resources, additional materials
- [Team](/community/team.md): Core-team
- [ทางเลือกอื่นๆ](/docs/about/alternatives.md): ประวัติความเป็นมาของแนวทางการออกแบบสถาปัตยกรรม (Architecture Approaches)
- [พันธกิจ (Mission)](/docs/about/mission.md): ในส่วนนี้เราจะอธิบายเป้าหมายและข้อจำกัดในการนำระเบียบวิธีนี้ไปใช้ ซึ่งเป็นสิ่งที่เรายึดถือในการพัฒนาระเบียบวิธีนี้
- [แรงบันดาลใจ (Motivation)](/docs/about/motivation.md): ไอเดียหลักของ Feature-Sliced Design คือการอำนวยความสะดวกและลดต้นทุนในการพัฒนาโปรเจกต์ที่ซับซ้อน โดยอิงจาก การรวบรวมผลการวิจัยและการหารือประสบการณ์จากนักพัฒนาที่หลากหลาย
- [การผลักดันในบริษัท](/docs/about/promote/for-company.md): โปรเจกต์และบริษัทจำเป็นต้องมี Methodology มั้ย?
- [การผลักดันในทีม](/docs/about/promote/for-team.md): - การ Onboard คนใหม่
- [มุมมองการ Integration](/docs/about/promote/integration.md): สรุป
- [การนำไปใช้บางส่วน (Partial Application)](/docs/about/promote/partial-application.md): จะนำ Methodology ไปใช้แค่บางส่วนได้มั้ย? มันสมเหตุสมผลรึเปล่า? แล้วถ้าฉันไม่สนใจมันล่ะ?
- [Abstractions (นามธรรม)](/docs/about/understanding/abstractions.md): กฎของ Leaky Abstractions
- [เกี่ยวกับสถาปัตยกรรม](/docs/about/understanding/architecture.md): ปัญหา
- [ประเภทของความรู้ในโปรเจกต์](/docs/about/understanding/knowledge-types.md): เราสามารถแบ่งแยก "ประเภทของความรู้" ในโปรเจกต์ได้ดังนี้:
- [การตั้งชื่อ (Naming)](/docs/about/understanding/naming.md): นักพัฒนาแต่ละคนมีประสบการณ์และบริบทที่ต่างกัน ซึ่งอาจนำไปสู่ความเข้าใจผิดในทีมเมื่อเรียก Entities เดียวกันด้วยชื่อที่ต่างกัน ตัวอย่างเช่น:
- [ขับเคลื่อนด้วยความต้องการ (Needs driven)](/docs/about/understanding/needs-driven.md): — คุณระบุเป้าหมายไม่ได้เหรอว่าฟีเจอร์ใหม่นี้จะแก้ปัญหาอะไร? หรือปัญหาคือตัวโจทย์เองก็ยังไม่ได้ตั้งมาให้ชัด? **ประเด็นคือ Methodology นี้ช่วยดึงเอานิยามของงานและเป้าหมายที่เป็นปัญหาออกมาให้เห็นชัดขึ้น**
- [สัญญาณของสถาปัตยกรรม (Signals of architecture)](/docs/about/understanding/signals.md): ถ้ามีข้อจำกัดในฝั่งสถาปัตยกรรม แสดงว่ามีเหตุผลที่ชัดเจนสำหรับสิ่งนั้น และมีผลกระทบถ้าเพิกเฉยมัน
- [แนวทางเรื่องแบรนด์ (Branding Guidelines)](/docs/branding.md): อัตลักษณ์ทางภาพ (Visual Identity) ของ FSD ขึ้นอยู่กับ Core-concepts ของมัน: Layered, Sliced self-contained parts, Parts & Compose, Segmented
- [Decomposition cheatsheet](/docs/get-started/cheatsheet.md): เก็บหน้านี้ไว้เป็นโพยดูแบบด่วนๆ เวลาที่ต้องตัดสินใจว่าจะแบ่งส่วน UI ยังไงดี ด้านล่างมีเวอร์ชัน PDF ให้โหลดด้วยนะ จะปริ้นท์ออกมาแปะฝาบ้านหรือเอาไว้หนุนนอนก็ได้ตามสะดวก
- [คำถามที่พบบ่อย (FAQ)](/docs/get-started/faq.md): ถ้ามีคำถามเพิ่มเติม แวะไปคุยกันได้ที่ Telegram chat, Discord community, และ GitHub Discussions
- [ภาพรวม (Overview)](/docs/get-started/overview.md): Feature-Sliced Design (FSD) คือแนวทางการออกแบบสถาปัตยกรรมสำหรับ frontend application พูดง่ายๆ ก็คือ เป็นการรวบรวมกฎและข้อตกลงในการจัดระเบียบโค้ดนั่นเอง เป้าหมายหลักคือทำให้โปรเจกต์เข้าใจง่ายและมีความเสถียร (Stable) เสมอ แม้ว่าความต้องการทางธุรกิจจะเปลี่ยนไปบ่อยแค่ไหนก็ตาม 🚀
- [บทเรียน (Tutorial)](/docs/get-started/tutorial.md): ส่วนที่ 1: ร่างบนกระดาษ (On paper)
- [การจัดการ API Requests](/docs/guides/examples/api-requests.md): handling-api-requests}
- [การยืนยันตัวตน (Authentication)](/docs/guides/examples/auth.md): โดยทั่วไป การ Authentication ประกอบด้วยขั้นตอนต่อไปนี้:
- [Autocomplete](/docs/guides/examples/autocompleted.md): เกี่ยวกับการ Decomposition ตาม Layers
- [Browser API](/docs/guides/examples/browser-api.md): เกี่ยวกับการทำงานกับ Browser API: localStorage, audio Api, bluetooth API, ฯลฯ
- [CMS](/docs/guides/examples/cms.md): ฟีเจอร์อาจจะแตกต่างกัน
- [Feedback](/docs/guides/examples/feedback.md): Errors, Alerts, Notifications, ...
- [i18n](/docs/guides/examples/i18n.md): วางไว้ที่ไหน? ทำงานกับมันยังไง?
- [Metric](/docs/guides/examples/metric.md): เกี่ยวกับวิธีการ Initialize metrics ในแอปพลิเคชัน
- [Monorepositories](/docs/guides/examples/monorepo.md): เกี่ยวกับการประยุกต์ใช้กับ Mono repositories, BFF, และ Microapps
- [Page layouts (เลย์เอาต์ของหน้า)](/docs/guides/examples/page-layout.md): ไกด์นี้จะสำรวจเรื่อง Abstraction ของ Page layout — เมื่อหลายๆ หน้าใช้โครงสร้างรวมๆ เหมือนกัน และต่างกันแค่เนื้อหาหลัก
- [Desktop/Touch platforms](/docs/guides/examples/platforms.md): เกี่ยวกับการประยุกต์ใช้ Methodology สำหรับ Desktop/Touch
- [SSR (Server-Side Rendering)](/docs/guides/examples/ssr.md): เกี่ยวกับการ Implement SSR โดยใช้ Methodology นี้
- [Theme (ธีม)](/docs/guides/examples/theme.md): ฉันควรวางโค้ดเกี่ยวกับธีมและ Palette ไว้ที่ไหน?
- [Types (ชนิดข้อมูล)](/docs/guides/examples/types.md): ไกด์นี้เกี่ยวข้องกับ Data types จากภาษาที่มี Type อย่าง TypeScript และอธิบายว่ามันอยู่ตรงไหนใน FSD
- [White Labels](/docs/guides/examples/white-labels.md): Figma, brand uikit, templates, ความสามารถในการปรับตัวกับแบรนด์ต่างๆ
- [Cross-import](/docs/guides/issues/cross-imports.md): Cross-import คือการ import ระหว่าง slices ที่แตกต่างกันแต่อยู่ใน layer เดียวกัน
- [Desegmentation](/docs/guides/issues/desegmented.md): Desegmentation (หรือที่รู้จักว่า Horizontal Slicing หรือ Packaging by Layer) คือรูปแบบการจัดระเบียบโค้ดที่ไฟล์ถูกจัดกลุ่มตามบทบาททางเทคนิค (Technical Roles) แทนที่จะเป็น Business Domains ที่มันรับผิดชอบ นี่หมายความว่าโค้ดที่มีฟังก์ชันทางเทคนิคคล้ายกันจะถูกเก็บไว้ที่เดียวกัน ไม่ว่ามันจะจัดการ Business logic อะไรก็ตาม
- [Excessive Entities](/docs/guides/issues/excessive-entities.md): Layer entities ใน Feature-Sliced Design เป็นหนึ่งใน Layer ล่างๆ ที่มีไว้สำหรับ Business logic เป็นหลัก นั่นทำให้มันเข้าถึงได้ง่าย — ทุก Layers ยกเว้น shared สามารถเข้าถึงมันได้ อย่างไรก็ตาม ความเป็น Global ของมันหมายความว่าการเปลี่ยนแปลงใน entities อาจส่งผลกระทบวงกว้าง ต้องใช้การ Design อย่างระมัดระวังเพื่อหลีกเลี่ยงการ Refactor ที่ราคาแพง
- [Routing](/docs/guides/issues/routes.md): สถานการณ์
- [การย้ายจากสถาปัตยกรรมที่ทำเอง (Custom Architecture)](/docs/guides/migration/from-custom.md): ไกด์นี้อธิบายแนวทางที่อาจเป็นประโยชน์เมื่อย้ายจาก Custom self-made architecture มาเป็น Feature-Sliced Design
- [การย้ายจาก v1 ไป v2](/docs/guides/migration/from-v1.md): ทำไมถึงต้อง v2?
- [การย้ายจาก v2.0 ไป v2.1](/docs/guides/migration/from-v2-0.md): การเปลี่ยนแปลงหลักใน v2.1 คือ Mental model ใหม่สำหรับการแยกส่วน Interface (Decomposition) — โดยเริ่มจาก Pages
- [การใช้ร่วมกับ Electron](/docs/guides/tech/with-electron.md): แอปพลิเคชัน Electron มีสถาปัตยกรรมพิเศษที่ประกอบด้วยหลาย Processes ซึ่งมีความรับผิดชอบต่างกัน การใช้ FSD ในบริบทนี้ต้องมีการปรับโครงสร้างให้เข้ากับธรรมชาติของ Electron
- [การใช้ร่วมกับ Next.js](/docs/guides/tech/with-nextjs.md): FSD สามารถใช้ร่วมกับ Next.js ได้ทั้งเวอร์ชัน App Router และ Pages Router หากคุณแก้ปัญหาความขัดแย้งหลักได้ — นั่นคือเรื่องโฟลเดอร์ app และ pages
- [การใช้ร่วมกับ NuxtJS](/docs/guides/tech/with-nuxtjs.md): เป็นไปได้ที่จะใช้ FSD ในโปรเจกต์ NuxtJS แต่จะเกิดความขัดแย้งเนื่องจากความแตกต่างระหว่างข้อกำหนดโครงสร้างโปรเจกต์ของ NuxtJS และหลักการของ FSD:
- [การใช้ร่วมกับ React Query](/docs/guides/tech/with-react-query.md): ปัญหาเรื่อง "จะวาง Keys ไว้ที่ไหน"
- [การใช้ร่วมกับ SvelteKit](/docs/guides/tech/with-sveltekit.md): เป็นไปได้ที่จะใช้ FSD ในโปรเจกต์ SvelteKit แต่จะเกิดความขัดแย้งเนื่องจากความแตกต่างระหว่างข้อกำหนดโครงสร้างของโปรเจกต์ SvelteKit และหลักการของ FSD:
- [เอกสารสำหรับ LLMs](/docs/llms.md): หน้านี้รวบรวมลิงก์และคำแนะนำสำหรับ LLM crawlers
- [Layers (เลเยอร์)](/docs/reference/layers.md): Layers เป็นระดับแรกของลำดับชั้นการจัดระเบียบใน Feature-Sliced Design จุดประสงค์คือเพื่อแยกโค้ดตามระดับความรับผิดชอบที่มันต้องการและจำนวน Modules อื่นๆ ในแอปที่มันพึ่งพา ทุก Layer มีความหมายทาง Semantic พิเศษที่จะช่วยคุณตัดสินใจว่าควรจัดสรรความรับผิดชอบให้โค้ดของคุณมากแค่ไหน
- [Public API](/docs/reference/public-api.md): Public API คือ สัญญา (Contract) ระหว่างกลุ่มของ Modules (เช่น Slice) กับโค้ดที่จะมาใช้งานมัน มันยังทำหน้าที่เป็นประตู (Gate) ที่อนุญาตให้เข้าถึง Object บางอย่างเท่านั้น และต้องผ่านทาง Public API นั้นๆ เท่านั้น
- [Slices และ Segments](/docs/reference/slices-segments.md): Slices
- [Feature-Sliced Design](/index.md): Architectural methodology for frontend projects