[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"_public_topic_publications_thi%E1%BA%BFt%20k%E1%BA%BF%20ph%E1%BA%A7n%20m%E1%BB%81m{\"limit\":5}":3,"_public_topic_byId_thiết kế phần mềm":11},{"code":4,"data":5,"meta":10},"SUCCESS",{"latest":6,"mostCited":7,"vietnamFeatured":8,"vietnamLatest":9},[],[],[],[],null,{"code":4,"data":12,"meta":10},{"id":13,"title":14,"description":15,"content":16,"term":13,"englishTitle":10,"synonyms":10,"definition":10,"discipline":10,"references":10,"faqs":10,"createUser":17,"publishUser":21,"keywords":25,"keywordCount":26,"enrichTopicLink":27,"status":28,"createTime":29,"updateTime":30,"publishTime":31,"linkEnrichedTime":10,"publicationScanTime":10,"contentErrorMessage":10,"viewCount":32,"relateTopics":33},"thiết kế phần mềm","Thiết kế phần mềm là gì? Các nghiên cứu khoa học liên quan","Thiết kế phần mềm là quá trình xác định cấu trúc và hành vi hệ thống nhằm chuyển đổi yêu cầu thành giải pháp kỹ thuật có thể triển khai được. Nó bao gồm việc lựa chọn kiến trúc, mô hình, phương pháp và nguyên lý để đảm bảo phần mềm có khả năng mở rộng, bảo trì và vận hành hiệu quả. ","\u003Cdiv>\u003Ch2>Định nghĩa thiết kế phần mềm\u003C\u002Fh2>\n\u003Cp>\nThiết kế phần mềm là quá trình xác định cấu trúc và hành vi của một hệ thống phần mềm nhằm đáp ứng các yêu cầu chức năng và phi chức năng. Nó là cầu nối giữa giai đoạn phân tích yêu cầu và quá trình lập trình, giúp chuyển đổi đặc tả thành giải pháp kỹ thuật cụ thể. Thiết kế phần mềm không chỉ bao gồm định nghĩa về cấu trúc hệ thống mà còn liên quan đến các quyết định về kiến trúc, giao diện, mô-đun, và luồng dữ liệu.\n\u003C\u002Fp>\n\u003Cp>\nThiết kế phần mềm được coi là một nghệ thuật kỹ thuật, nơi các kỹ sư cần cân nhắc giữa độ phức tạp, hiệu suất, khả năng bảo trì và chi phí. Quá trình thiết kế thành công thường sử dụng cả nguyên lý thiết kế và mẫu thiết kế (design patterns) để tạo ra hệ thống có tính mở rộng và chống chịu tốt với thay đổi. Thiết kế không tốt thường dẫn đến phần mềm khó phát triển thêm, dễ lỗi và tốn kém về lâu dài.\n\u003C\u002Fp>\n\u003Cp>\nNguồn: \u003Ca href=\"https:\u002F\u002Fwww.ibm.com\u002Fdocs\u002Fen\u002Fengineering-lifecycle-management-suite\u002Fdesign-management\" target=\"_blank\">IBM - Design Management\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2>Các cấp độ thiết kế phần mềm\u003C\u002Fh2>\n\u003Cp>\nThiết kế phần mềm diễn ra ở nhiều tầng trừu tượng, được chia thành ba cấp độ chính: thiết kế kiến trúc (architectural design), thiết kế mức cao (high-level design) và thiết kế chi tiết (low-level design). Mỗi cấp độ giải quyết một mặt khác nhau của hệ thống, từ cái nhìn tổng quan đến chi tiết thực thi.\n\u003C\u002Fp>\n\u003Cp>\nBảng phân biệt các cấp độ thiết kế:\n\u003C\u002Fp>\u003Ctable border=\"1\" cellpadding=\"6\" cellspacing=\"0\">\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Cấp độ\u003C\u002Fth>\n      \u003Cth>Phạm vi\u003C\u002Fth>\n      \u003Cth>Đối tượng chính\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Kiến trúc\u003C\u002Ftd>\n      \u003Ctd>Toàn hệ thống\u003C\u002Ftd>\n      \u003Ctd>Thành phần, giao tiếp, luồng chính\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Mức cao\u003C\u002Ftd>\n      \u003Ctd>Nhóm mô-đun\u003C\u002Ftd>\n      \u003Ctd>API, lớp, tương tác logic\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Chi tiết\u003C\u002Ftd>\n      \u003Ctd>Bên trong mô-đun\u003C\u002Ftd>\n      \u003Ctd>Thuật toán, cấu trúc dữ liệu\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>\u003C\u002Fp>\n\u003Cp>\nThiết kế tầng cao ảnh hưởng đến khả năng phân chia công việc, còn thiết kế chi tiết quyết định hiệu suất xử lý. Việc đồng bộ giữa các cấp độ thiết kế giúp tránh xung đột và giảm rủi ro kỹ thuật.\n\u003C\u002Fp>\n\u003Cp>\nNguồn: \u003Ca href=\"https:\u002F\u002Fwww.geeksforgeeks.org\u002Fsoftware-engineering-software-design-process\u002F\" target=\"_blank\">GeeksForGeeks - Software Design Process\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2>Nguyên lý thiết kế phần mềm\u003C\u002Fh2>\n\u003Cp>\nThiết kế phần mềm tốt đòi hỏi tuân thủ nhiều nguyên lý cơ bản nhằm đảm bảo chất lượng, dễ bảo trì và khả năng tái sử dụng. Một số nguyên lý thiết kế phổ biến bao gồm: phân tách mối quan tâm (separation of concerns), ít phụ thuộc (low coupling), tính kết dính cao (high cohesion), và đơn nhiệm vụ (single responsibility).\n\u003C\u002Fp>\n\u003Cp>\nCác nguyên lý thiết kế hướng đối tượng nổi bật thường được gộp lại trong bộ nguyên lý SOLID:\n\u003C\u002Fp>\u003Cul>\n  \u003Cli>\u003Cstrong>S:\u003C\u002Fstrong> Single Responsibility Principle\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>O:\u003C\u002Fstrong> Open\u002FClosed Principle\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>L:\u003C\u002Fstrong> Liskov Substitution Principle\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>I:\u003C\u002Fstrong> Interface Segregation Principle\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>D:\u003C\u002Fstrong> Dependency Inversion Principle\u003C\u002Fli>\n\u003C\u002Ful>\nÁp dụng đúng các nguyên lý trên giúp hệ thống dễ thay đổi, mở rộng và có cấu trúc rõ ràng. Đây cũng là nền tảng cho việc sử dụng mẫu thiết kế trong giai đoạn triển khai.\n\u003Cp>\u003C\u002Fp>\n\u003Cp>\nNguồn: \u003Ca href=\"https:\u002F\u002Frefactoring.guru\u002Fdesign-patterns\u002Fprinciples\" target=\"_blank\">Refactoring Guru - Design Principles\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2>Phương pháp thiết kế phần mềm\u003C\u002Fh2>\n\u003Cp>\nThiết kế phần mềm có thể áp dụng nhiều phương pháp khác nhau tùy theo đặc điểm dự án và yêu cầu nghiệp vụ. Các phương pháp phổ biến bao gồm thiết kế hướng đối tượng (Object-Oriented Design - OOD), thiết kế chức năng (Functional Design), thiết kế hướng dữ liệu (Data-Centric Design) và thiết kế theo miền (Domain-Driven Design - DDD).\n\u003C\u002Fp>\n\u003Cp>\nBảng so sánh một số phương pháp tiêu biểu:\n\u003C\u002Fp>\u003Ctable border=\"1\" cellpadding=\"6\" cellspacing=\"0\">\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Phương pháp\u003C\u002Fth>\n      \u003Cth>Trọng tâm\u003C\u002Fth>\n      \u003Cth>Ưu điểm\u003C\u002Fth>\n      \u003Cth>Hạn chế\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>OOD\u003C\u002Ftd>\n      \u003Ctd>Lớp, đối tượng\u003C\u002Ftd>\n      \u003Ctd>Dễ mở rộng, dễ hiểu\u003C\u002Ftd>\n      \u003Ctd>Phức tạp khi hệ thống lớn\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Functional\u003C\u002Ftd>\n      \u003Ctd>Hàm thuần, không trạng thái\u003C\u002Ftd>\n      \u003Ctd>Dễ kiểm thử, ít lỗi\u003C\u002Ftd>\n      \u003Ctd>Khó bảo trì nếu quá nhiều phụ thuộc\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>DDD\u003C\u002Ftd>\n      \u003Ctd>Mô hình nghiệp vụ\u003C\u002Ftd>\n      \u003Ctd>Sát thực tế, dễ tái cấu trúc\u003C\u002Ftd>\n      \u003Ctd>Yêu cầu hiểu sâu domain\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\u003Cp>\u003C\u002Fp>\n\u003Cp>\nViệc chọn đúng phương pháp là yếu tố chiến lược, ảnh hưởng đến cách tổ chức mã nguồn và quy trình phát triển phần mềm sau này.\nNguồn: \u003Ca href=\"https:\u002F\u002Fmartinfowler.com\u002Ftags\u002Fdesign.html\" target=\"_blank\">Martin Fowler - Design Topics\u003C\u002Fa>\n\u003C\u002Fp>\n\u003Ch2>Mô hình thiết kế phần mềm\u003C\u002Fh2>\n\u003Cp>\nMô hình thiết kế phần mềm là cách tổ chức kiến trúc hệ thống theo những nguyên tắc định sẵn nhằm tăng khả năng mở rộng, bảo trì và tái sử dụng. Các mô hình phổ biến bao gồm: MVC (Model-View-Controller), MVVM (Model-View-ViewModel), Microservices, Client-Server, Layered Architecture.\n\u003C\u002Fp>\n\u003Cp>\nMỗi mô hình có ưu điểm và hạn chế riêng tùy theo loại ứng dụng và quy mô hệ thống. Ví dụ, mô hình Microservices phù hợp cho các hệ thống phân tán lớn, trong khi MVC được ứng dụng rộng rãi trong phát triển web.\n\u003C\u002Fp>\n\u003Cp>\nBảng so sánh một số mô hình:\n\u003C\u002Fp>\u003Ctable border=\"1\" cellpadding=\"6\" cellspacing=\"0\">\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Mô hình\u003C\u002Fth>\n      \u003Cth>Đặc điểm\u003C\u002Fth>\n      \u003Cth>Ưu điểm\u003C\u002Fth>\n      \u003Cth>Hạn chế\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>MVC\u003C\u002Ftd>\n      \u003Ctd>Phân tách giao diện và logic\u003C\u002Ftd>\n      \u003Ctd>Dễ bảo trì, kiểm thử\u003C\u002Ftd>\n      \u003Ctd>Khó kiểm soát dữ liệu động\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Microservices\u003C\u002Ftd>\n      \u003Ctd>Thành phần độc lập\u003C\u002Ftd>\n      \u003Ctd>Triển khai riêng biệt, mở rộng linh hoạt\u003C\u002Ftd>\n      \u003Ctd>Phức tạp về giao tiếp và bảo mật\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Layered\u003C\u002Ftd>\n      \u003Ctd>Chia tầng: UI, logic, dữ liệu\u003C\u002Ftd>\n      \u003Ctd>Dễ tách biệt chức năng\u003C\u002Ftd>\n      \u003Ctd>Hiệu suất thấp nếu tầng phụ thuộc sâu\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\nNguồn: \u003Ca href=\"https:\u002F\u002Fdocs.microsoft.com\u002Fen-us\u002Faspnet\u002Fmvc\u002Foverview\u002Foverview\" target=\"_blank\">Microsoft - MVC Overview\u003C\u002Fa>\n\u003Cp>\u003C\u002Fp>\n\n\u003Ch2>Biểu đồ và công cụ thiết kế\u003C\u002Fh2>\n\u003Cp>\nĐể hỗ trợ quá trình thiết kế phần mềm, các kỹ sư thường sử dụng các sơ đồ trực quan giúp truyền đạt cấu trúc và hành vi hệ thống. Ngôn ngữ UML (Unified Modeling Language) là chuẩn phổ biến nhất, bao gồm các loại sơ đồ như: sơ đồ lớp, sơ đồ trình tự, sơ đồ thành phần, sơ đồ trạng thái.\n\u003C\u002Fp>\n\u003Cp>\nNgoài UML, sơ đồ luồng dữ liệu (DFD), sơ đồ ERD (Entity-Relationship Diagram) cũng thường dùng để biểu diễn cơ sở dữ liệu và hệ thống xử lý dữ liệu. Các công cụ hỗ trợ thiết kế đi kèm gồm:\n\u003C\u002Fp>\u003Cul>\n  \u003Cli>Draw.io, Lucidchart: Dễ sử dụng, trực tuyến\u003C\u002Fli>\n  \u003Cli>StarUML, Enterprise Architect: Hỗ trợ đầy đủ UML\u003C\u002Fli>\n  \u003Cli>PlantUML: Tạo biểu đồ bằng mã văn bản\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\nSử dụng sơ đồ đúng cách giúp giảm hiểu sai yêu cầu, tạo cơ sở thống nhất giữa các thành viên trong nhóm phát triển.\nNguồn: \u003Ca href=\"https:\u002F\u002Fwww.uml-diagrams.org\u002F\" target=\"_blank\">UML Diagrams Resource\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2>Thiết kế hướng kiến trúc và thiết kế chi tiết\u003C\u002Fh2>\n\u003Cp>\nThiết kế kiến trúc (architectural design) tập trung vào cấu trúc tổng thể của hệ thống, xác định thành phần chính, cách thức các phần tương tác và các chuẩn giao tiếp giữa chúng. Mục tiêu là đảm bảo hệ thống có khả năng mở rộng, phân tán và dễ tích hợp.\n\u003C\u002Fp>\n\u003Cp>\nTrong khi đó, thiết kế chi tiết (detailed design) đi sâu vào bên trong mỗi mô-đun, mô tả cấu trúc dữ liệu, thuật toán và luồng xử lý. Đây là giai đoạn chuẩn bị để các lập trình viên có thể viết mã theo đặc tả rõ ràng.\n\u003C\u002Fp>\n\u003Cp>\nMối quan hệ giữa hai loại thiết kế này là tương hỗ: kiến trúc vững chắc tạo điều kiện cho chi tiết ổn định; chi tiết tốt giúp hiện thực kiến trúc hiệu quả. Việc phối hợp chặt chẽ giúp giảm xung đột logic và kỹ thuật trong triển khai.\nNguồn: \u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Four-work\u002Fsoftware-architecture\u002F\" target=\"_blank\">SEI - Software Architecture\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2>Tác động của thiết kế đến chất lượng phần mềm\u003C\u002Fh2>\n\u003Cp>\nChất lượng phần mềm chịu ảnh hưởng trực tiếp từ chất lượng thiết kế. Một thiết kế hợp lý giúp hệ thống hoạt động ổn định, dễ nâng cấp, kiểm thử và giảm thiểu lỗi. Ngược lại, thiết kế tệ dẫn đến nợ kỹ thuật, làm tăng chi phí bảo trì, thời gian phát triển và rủi ro vận hành.\n\u003C\u002Fp>\n\u003Cp>\nCác yếu tố chất lượng bị ảnh hưởng bởi thiết kế bao gồm:\n\u003C\u002Fp>\u003Cul>\n  \u003Cli>\u003Cstrong>Hiệu năng:\u003C\u002Fstrong> Do quyết định thuật toán và cấu trúc dữ liệu\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Bảo trì:\u003C\u002Fstrong> Phụ thuộc vào mức độ phân tách mô-đun\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Bảo mật:\u003C\u002Fstrong> Thiết kế lỗ hổng sẽ mở ra tấn công\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Khả năng kiểm thử:\u003C\u002Fstrong> Thiết kế tốt dễ áp dụng kiểm thử tự động\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\nMột số công cụ hỗ trợ đánh giá thiết kế phần mềm:\n\u003C\u002Fp>\u003Cul>\n  \u003Cli>SonarQube: Đánh giá chất lượng mã nguồn\u003C\u002Fli>\n  \u003Cli>Code Climate: Phân tích độ phức tạp\u003C\u002Fli>\n  \u003Cli>Structure101: Phân tích phụ thuộc kiến trúc\u003C\u002Fli>\n\u003C\u002Ful>\nNguồn: \u003Ca href=\"https:\u002F\u002Fieeexplore.ieee.org\u002Fdocument\u002F1642971\" target=\"_blank\">IEEE - Quality of Software Design\u003C\u002Fa>\n\u003Cp>\u003C\u002Fp>\n\n\u003Ch2>Thiết kế phần mềm trong phát triển hiện đại (Agile, DevOps)\u003C\u002Fh2>\n\u003Cp>\nTrong các mô hình phát triển hiện đại như Agile và DevOps, thiết kế phần mềm không còn là bước riêng biệt đầu dự án mà trở thành quá trình liên tục. Thiết kế phải linh hoạt, thích nghi nhanh với yêu cầu thay đổi và được điều chỉnh trong mỗi vòng lặp phát triển.\n\u003C\u002Fp>\n\u003Cp>\nKhái niệm \"evolutionary design\" mô tả việc xây dựng hệ thống theo hướng mở, từng bước hoàn thiện kiến trúc khi có thêm hiểu biết. Các kỹ thuật như TDD (Test-Driven Development), Refactoring và CI\u002FCD giúp duy trì chất lượng thiết kế khi thay đổi liên tục.\n\u003C\u002Fp>\n\u003Cp>\nTrong DevOps, thiết kế còn bao gồm cả khía cạnh triển khai, như cấu trúc hạ tầng, logging, giám sát và bảo mật. Một thiết kế hiện đại cần tính đến yếu tố vận hành (run-time) ngay từ lúc thiết kế logic hệ thống.\nNguồn: \u003Ca href=\"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FEvolutionaryDesign.html\" target=\"_blank\">Martin Fowler - Evolutionary Design\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Ch2>Tài liệu tham khảo\u003C\u002Fh2>\n\u003Col>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.ibm.com\u002Fdocs\u002Fen\u002Fengineering-lifecycle-management-suite\u002Fdesign-management\" target=\"_blank\">IBM - Design Management\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.geeksforgeeks.org\u002Fsoftware-engineering-software-design-process\u002F\" target=\"_blank\">GeeksForGeeks - Software Design Process\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Frefactoring.guru\u002Fdesign-patterns\u002Fprinciples\" target=\"_blank\">Refactoring Guru - Design Principles\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fmartinfowler.com\u002Ftags\u002Fdesign.html\" target=\"_blank\">Martin Fowler - Design Topics\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fdocs.microsoft.com\u002Fen-us\u002Faspnet\u002Fmvc\u002Foverview\u002Foverview\" target=\"_blank\">Microsoft - MVC Overview\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.uml-diagrams.org\u002F\" target=\"_blank\">UML Diagrams Resource\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.sei.cmu.edu\u002Four-work\u002Fsoftware-architecture\u002F\" target=\"_blank\">SEI - Software Architecture\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fieeexplore.ieee.org\u002Fdocument\u002F1642971\" target=\"_blank\">IEEE - Quality of Software Design\u003C\u002Fa>\u003C\u002Fli>\n  \u003Cli>\u003Ca href=\"https:\u002F\u002Fmartinfowler.com\u002Fbliki\u002FEvolutionaryDesign.html\" target=\"_blank\">Martin Fowler - Evolutionary Design\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003C\u002Fdiv>",{"id":18,"researcherId":10,"name":19,"imageUrl":20},2681,"Cuong Ta","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocKFuWh0ZD601Hp0_V_2xAK3kIOs20Kyv3V5ZLBo6fwfjyymJYzE=s96-c",{"id":22,"researcherId":10,"name":23,"imageUrl":24},2889,"Lê Xuân Niên","https:\u002F\u002Flh3.googleusercontent.com\u002Fa\u002FACg8ocLuyWIkhyP2W5E59cKwN7ciI2nbjMGUpXO9rVQquC826ujzkqhU=s96-c",[13],1,false,"PUBLISHED","2025-10-02T07:05:41.026+00:00","2025-10-06T11:01:33.524+00:00","2025-10-06T11:01:33.517+00:00",130,[34,44,47,57,67,71,82,88,99,105],{"id":35,"title":36,"term":35,"englishTitle":37,"definition":38,"discipline":39,"disciplineCode":40,"disciplineLabel":41,"disciplineColor":42,"disciplineIcon":43},"kiến trúc phần cứng","Kiến trúc phần cứng là gì? Các bài báo nghiên cứu khoa học","Hardware architecture \u002F Computer architecture","Kiến trúc phần cứng là thiết kế cấu trúc và mô hình tổ chức logic của các thành phần vật lý trong hệ thống máy tính, quy định cách thức tương tác giữa bộ xử lý trung tâm, bộ nhớ và các hệ thống bus giao tiếp.","ENGINEERING_TECHNOLOGY","engineering-technology","Kỹ thuật và công nghệ","#5B62F4","cpu",{"id":45,"title":46,"term":45,"englishTitle":10,"definition":10,"discipline":10,"disciplineCode":10,"disciplineLabel":10,"disciplineColor":10,"disciplineIcon":10},"cắt lớp vi tính","Cắt lớp vi tính là gì? Các công bố khoa học về Cắt lớp vi tính",{"id":48,"title":49,"term":48,"englishTitle":50,"definition":51,"discipline":52,"disciplineCode":53,"disciplineLabel":54,"disciplineColor":55,"disciplineIcon":56},"điều kiện cần và đủ","Điều kiện cần và đủ là gì? Các bài báo nghiên cứu khoa học","dieu kien can va du","khái niệm và đối tượng nghiên cứu cơ bản trong khoa học nông nghiệp, phản ánh các đặc trưng bản chất, cơ chế vận hành và các quy luật tương tác hệ thống trong thực tiễn.","AGRICULTURAL_SCIENCES","agricultural-sciences","Khoa học nông nghiệp","#2F9E44","sprout",{"id":58,"title":59,"term":58,"englishTitle":60,"definition":61,"discipline":62,"disciplineCode":63,"disciplineLabel":64,"disciplineColor":65,"disciplineIcon":66},"polymorphism","Polymorphism là gì? Các bài nghiên cứu khoa học liên quan","Polymorphism","Polymorphism (tính đa hình) là hiện tượng tồn tại đồng thời hai hay nhiều biến thể hình thái, cấu trúc tinh thể hoặc alen di truyền phân tử khác nhau trong cùng một quần thể sinh học hoặc một hợp chất vật chất.","NATURAL_SCIENCES","natural-sciences","Khoa học tự nhiên","#0E9F9C","atom",{"id":68,"title":69,"term":68,"englishTitle":60,"definition":70,"discipline":62,"disciplineCode":63,"disciplineLabel":64,"disciplineColor":65,"disciplineIcon":66},"đa hình","Đa hình là gì? Các công bố khoa học về Đa hình","Đa hình (polymorphism) là hiện tượng sinh học trong đó hai hoặc nhiều biến dị kiểu hình hoặc kiểu gen phân biệt (như đa hình đơn nucleotide - SNP) cùng tồn tại ổn định trong một quần thể sinh vật với tần số vượt quá đột biến ngẫu nhiên.",{"id":72,"title":73,"term":74,"englishTitle":75,"definition":76,"discipline":77,"disciplineCode":78,"disciplineLabel":79,"disciplineColor":80,"disciplineIcon":81},"khuyết hổng phần mềm","Khuyết hổng phần mềm là gì? Các công bố khoa học về Khuyết hổng phần mềm","Khuyết hổng phần mềm","Soft tissue defect","Khuyết hổng phần mềm là tình trạng tổn thương mất liên tục và thiếu hụt các lớp cấu trúc che phủ hoặc nâng đỡ (da, tổ chức dưới da, cân, cơ) do chấn thương năng lượng cao, cắt bỏ khối u ác tính hoặc biến chứng nhiễm trùng hoại tử.","MEDICAL_HEALTH_SCIENCES","medical-health-sciences","Khoa học y - dược","#D6336C","stethoscope",{"id":83,"title":84,"term":85,"englishTitle":86,"definition":87,"discipline":77,"disciplineCode":78,"disciplineLabel":79,"disciplineColor":80,"disciplineIcon":81},"vét hạch cổ","Vét hạch cổ là gì? Ý nghĩa và ứng dụng chuyên sâu","Vét hạch cổ","neck dissection","Vét hạch cổ (neck dissection) là phẫu thuật chuyên khoa đầu mặt cổ nhằm nạo vét và loại bỏ triệt để các nhóm hạch bạch huyết cùng các mô liên kết xung quanh vùng cổ bị di căn hoặc có nguy cơ cao di căn vi thể từ các khối u ác tính nguyên phát vùng đầu cổ, giúp kiểm soát tại chỗ, định giai đoạn bệnh chính xác và cải thiện tiên lượng sống còn cho người bệnh.",{"id":89,"title":90,"term":91,"englishTitle":92,"definition":93,"discipline":94,"disciplineCode":95,"disciplineLabel":96,"disciplineColor":97,"disciplineIcon":98},"nguyễn du","Nguyễn Du là gì? Ý nghĩa và ứng dụng chuyên sâu","Nguyễn Du","Nguyen Du","Nguyễn Du (1765–1820), tên chữ Tố Như, hiệu Thanh Hiên, là đại thi hào của dân tộc Việt Nam và Danh nhân văn hóa thế giới, tác giả kiệt tác Truyện Kiều (Đoạn trường tân thanh) cùng nhiều thi phẩm chữ Hán và chữ Nôm bất hủ kết tinh chủ nghĩa nhân đạo sâu sắc và đỉnh cao nghệ thuật ngôn ngữ tiếng Việt.","HUMANITIES","humanities","Nhân văn và nghệ thuật","#9333EA","book-open",{"id":100,"title":101,"term":102,"englishTitle":103,"definition":104,"discipline":77,"disciplineCode":78,"disciplineLabel":79,"disciplineColor":80,"disciplineIcon":81},"hồ sơ bệnh án","Hồ sơ bệnh án là gì? Ý nghĩa và ứng dụng chuyên sâu","Hồ sơ bệnh án","medical record","Hồ sơ bệnh án (medical record \u002F health record) là tập hợp tài liệu y tế, pháp lý và hành chính ghi chép toàn diện, liên tục và bảo mật quá trình thăm khám, chẩn đoán, điều trị, chăm sóc và diễn biến bệnh lý của người bệnh trong suốt thời gian điều trị tại cơ sở y tế.",{"id":106,"title":107,"term":108,"englishTitle":108,"definition":109,"discipline":62,"disciplineCode":63,"disciplineLabel":64,"disciplineColor":65,"disciplineIcon":66},"coccidioides posadasii","Coccidioides posadasii là gì? Ý nghĩa và ứng dụng chuyên sâu","Coccidioides posadasii","Coccidioides posadasii là một loài vi nấm lưỡng hình gây bệnh thuộc chi Coccidioides, tồn tại ở dạng nấm sợi trong đất khô cằn vùng dịch tễ châu Mỹ và chuyển thành dạng cầu nang chứa đầy nội bào tử trong mô vật chủ, là căn nguyên gây bệnh nấm Coccidioidomycosis (sốt Thung lũng)."]