Thiết kế phần mềm so với Kiến trúc phần mềm [đã đóng]

Ai đó có thể giải thích sự khác biệt giữa Thiết kế phần mềm và Kiến trúc phần mềm?

Cụ thể hơn; nếu bạn bảo ai đó trình bày cho bạn 'thiết kế' - bạn sẽ mong họ trình bày điều gì? Tương tự với "kiến trúc".

Hiểu biết hiện tại của tôi là:

• Thiết kế: Sơ đồ UML / biểu đồ luồng / khung lưới đơn giản (cho UI) cho một mô-đun / phần cụ thể của hệ thống
• Kiến trúc: sơ đồ thành phần (hiển thị cách các mô-đun khác nhau của hệ thống giao tiếp với nhau và các hệ thống khác), ngôn ngữ nào sẽ được sử dụng, các mẫu ...?

Sửa tôi nếu tôi sai. Tôi đã giới thiệu Wikipedia có các bài viết về http://en.wikipedia.org/wiki/Software_design và http://en.wikipedia.org/wiki/Software_arch architecture , nhưng tôi không chắc liệu tôi đã hiểu đúng chưa.

Bạn nói đúng. Kiến trúc của một hệ thống là "bộ xương" của nó. Đó là mức độ trừu tượng cao nhất của một hệ thống. Loại lưu trữ dữ liệu nào hiện diện, làm thế nào để các mô-đun tương tác với nhau, hệ thống phục hồi đang diễn ra. Cũng giống như các mẫu thiết kế, có các mẫu kiến ​​trúc: MVC, thiết kế 3 lớp, v.v.

Thiết kế phần mềm là về thiết kế các mô-đun / thành phần riêng lẻ. Các trách nhiệm, chức năng, của mô-đun x là gì? Của lớp Y? Nó có thể làm gì, và những gì không? Những mẫu thiết kế có thể được sử dụng?

Vì vậy, trong ngắn hạn, kiến ​​trúc phần mềm thiên về thiết kế của toàn bộ hệ thống, trong khi thiết kế phần mềm nhấn mạnh vào cấp độ mô-đun / thành phần / lớp.

Trong một số mô tả về SDLC (Vòng đời phát triển phần mềm) chúng có thể hoán đổi cho nhau, nhưng điều quan trọng là chúng khác biệt. Chúng cùng một lúc: (1) giai đoạn khác nhau , (2) lĩnh vực trách nhiệm và (3) mức độ ra quyết định .

• Kiến trúc là bức tranh lớn hơn: sự lựa chọn của các khung, ngôn ngữ, phạm vi, mục tiêu và các phương pháp cấp cao ( Rational , thác nước , nhanh nhẹn , v.v.).
• Thiết kế là bức tranh nhỏ hơn: kế hoạch về cách tổ chức mã; các hợp đồng giữa các bộ phận khác nhau của hệ thống sẽ trông như thế nào; việc thực hiện liên tục các phương pháp và mục tiêu của dự án. Đặc điểm kỹ thuật được viết trong giai đoạn này.

Hai giai đoạn này dường như sẽ hòa trộn với nhau vì những lý do khác nhau.

1. Các dự án nhỏ hơn thường không có đủ phạm vi để tách kế hoạch thành các giai đoạn này.
2. Một dự án có thể là một phần của một dự án lớn hơn, và do đó các phần của cả hai giai đoạn đã được quyết định. (Hiện đã có cơ sở dữ liệu, quy ước, tiêu chuẩn, giao thức, khung, mã có thể tái sử dụng, v.v.)
3. Những cách nghĩ mới hơn về SDLC (xem các phương pháp Agile ) phần nào sắp xếp lại phương pháp truyền thống này. Thiết kế (kiến trúc ở mức độ thấp hơn) diễn ra trong suốt SDLC theo mục đích . Thường có nhiều lần lặp đi lặp lại trong đó toàn bộ quá trình xảy ra lặp đi lặp lại .
4. Phát triển phần mềm rất phức tạp và khó lập kế hoạch, nhưng khách hàng / người quản lý / nhân viên bán hàng thường làm cho nó khó hơn bằng cách thay đổi mục tiêu và yêu cầu giữa dòng. Thiết kế và thậm chí các quyết định kiến ​​trúc phải tự làm sau này trong dự án cho dù đó là kế hoạch hay không.

Ngay cả khi các giai đoạn hoặc lĩnh vực trách nhiệm kết hợp với nhau và xảy ra ở mọi nơi, vẫn luôn tốt để biết mức độ ra quyết định nào đang xảy ra. (Chúng ta có thể tiếp tục với điều này. Tôi đang cố gắng tóm tắt.) Tôi sẽ kết thúc bằng: Ngay cả khi dự án của bạn không có giai đoạn thiết kế hoặc kiến ​​trúc chính thức / AOR / documentaiton, nó vẫn xảy ra cho dù có ai Có ý thức làm điều đó hay không. Nếu không ai quyết định làm kiến ​​trúc, thì một điều mặc định xảy ra có lẽ là kém. Ditto cho thiết kế. Những khái niệm này gần như quan trọng hơn nếu không có giai đoạn chính thức đại diện cho chúng.

Kiến trúc là chiến lược, trong khi Thiết kế là chiến thuật.

Kiến trúc bao gồm các khung, công cụ, mô hình lập trình, các tiêu chuẩn kỹ thuật phần mềm dựa trên thành phần, các nguyên tắc cấp cao ..

Trong khi thiết kế là một hoạt động liên quan đến các ràng buộc cục bộ, chẳng hạn như các mẫu thiết kế, thành ngữ lập trình và tái cấu trúc.

Tôi tìm thấy điều này khi tôi đang tìm kiếm sự phân biệt đơn giản giữa kiến ​​trúc và thiết kế;
Bạn nghĩ gì về cách nhìn này:

• kiến trúc là "cái gì" chúng ta đang xây dựng;
• thiết kế là "làm thế nào" chúng ta đang xây dựng;

1. Kiến trúc có nghĩa là cấu trúc khái niệm và tổ chức logic của một máy tính hoặc hệ thống dựa trên máy tính.

   Thiết kế có nghĩa là một kế hoạch hoặc bản vẽ được tạo ra để hiển thị giao diện và chức năng hoặc hoạt động của một hệ thống hoặc một đối tượng trước khi nó được thực hiện.

2. Nếu bạn là một kiến ​​trúc sư của thành phố, thì bạn đang xác định cách nó hoạt động trong hệ thống lớn hơn.

   Nếu bạn đang thiết kế thành công cùng một thành phần, bạn đang xác định cách nó hoạt động bên trong.

Tất cả kiến ​​trúc là thiết kế nhưng KHÔNG phải tất cả thiết kế là kiến ​​trúc.

Whatmột phần là Thiết kế, Howlà sự triển khai cụ thể và giao điểm của Whatvà Howlà Kiến trúc.

Hình ảnh để phân biệt Kiến trúc và Thiết kế :

Ngoài ra còn có các quyết định thiết kế, không có ý nghĩa về mặt kiến ​​trúc, tức là không thuộc về ngành kiến ​​trúc của thiết kế. Ví dụ, một số quyết định thiết kế nội bộ của một số thành phần, như lựa chọn thuật toán, lựa chọn cấu trúc dữ liệu, v.v.

Bất kỳ quyết định thiết kế nào không thể nhìn thấy bên ngoài ranh giới thành phần của nó là thiết kế bên trong của thành phần và không mang tính kiến ​​trúc. Đây là những quyết định thiết kế mà kiến ​​trúc sư hệ thống sẽ tùy ý người thiết kế mô-đun hoặc nhóm thực hiện miễn là thiết kế của họ không phá vỡ các ràng buộc kiến ​​trúc do kiến ​​trúc cấp hệ thống áp đặt.

Liên kết cung cấp tương tự tốt

Tôi nói bạn đúng, theo lời của tôi;

Kiến trúc là sự phân bổ các yêu cầu hệ thống cho các yếu tố hệ thống. Bốn tuyên bố về một kiến ​​trúc:

1. Nó có thể giới thiệu các yêu cầu phi chức năng như ngôn ngữ hoặc các mẫu.
2. Nó xác định sự tương tác giữa các thành phần, giao diện, thời gian, v.v.
3. Nó sẽ không giới thiệu chức năng mới,
4. Nó phân bổ các chức năng (được thiết kế) mà hệ thống dự định thực hiện cho các phần tử.

Kiến trúc là một bước kỹ thuật thiết yếu khi sự phức tạp của hệ thống được chia nhỏ.

Ví dụ: Hãy nghĩ về ngôi nhà của bạn, bạn không cần một kiến ​​trúc sư cho nhà bếp của bạn (chỉ có một yếu tố liên quan) nhưng tòa nhà hoàn chỉnh cần một số định nghĩa tương tác, như cửa ra vào và mái nhà .

Thiết kế là một đại diện thông tin của việc thực hiện (đề xuất) của chức năng. Nó nhằm mục đích khơi gợi phản hồi và thảo luận với các bên liên quan. Nó có thể là thực hành tốt nhưng không phải là một bước kỹ thuật thiết yếu .

Sẽ thật tuyệt khi thấy thiết kế nhà bếp nhìn thấy trước khi nhà bếp được cài đặt nhưng nó không cần thiết cho yêu cầu nấu ăn :

Nếu tôi nghĩ về nó, bạn có thể nói:

• kiến trúc dành cho công chúng / kỹ sư ở mức độ trừu tượng chi tiết hơn
• thiết kế dành cho công chúng ở mức độ trừu tượng ít chi tiết hơn

Lời nhắc của tôi:

• Chúng tôi có thể thay đổi Thiết kế mà không cần hỏi ai đó
• Nếu chúng tôi thay đổi Kiến trúc, chúng tôi cần liên lạc với ai đó (nhóm, khách hàng, các bên liên quan, ...)

Tôi nghĩ rằng chúng ta nên sử dụng quy tắc sau để xác định khi chúng ta nói về Thiết kế và Kiến trúc: Nếu các yếu tố của một bức tranh phần mềm bạn tạo có thể được ánh xạ từ một đến một cấu trúc cú pháp ngôn ngữ lập trình, thì đó là Thiết kế, nếu không phải là Kiến trúc.

Vì vậy, ví dụ, nếu bạn đang xem sơ đồ lớp hoặc sơ đồ tuần tự, bạn có thể ánh xạ một lớp và các mối quan hệ của chúng sang ngôn ngữ Lập trình hướng đối tượng bằng cách sử dụng cấu trúc cú pháp Lớp. Đây rõ ràng là Thiết kế. Ngoài ra, điều này có thể mang đến một cuộc thảo luận rằng cuộc thảo luận này có liên quan đến ngôn ngữ lập trình mà bạn sẽ sử dụng để triển khai một hệ thống phần mềm. Nếu bạn sử dụng Java, ví dụ trước áp dụng, vì Java là Ngôn ngữ lập trình hướng đối tượng. Nếu bạn đưa ra một sơ đồ hiển thị các gói và các phụ thuộc của nó, thì đó cũng là Thiết kế. Bạn có thể ánh xạ phần tử (một gói trong trường hợp này) sang cấu trúc cú pháp Java.

Bây giờ, giả sử ứng dụng Java của bạn được chia thành các mô-đun và mỗi mô-đun là một tập hợp các gói (được biểu diễn dưới dạng một đơn vị triển khai tệp jar) và bạn sẽ thấy một sơ đồ chứa các mô-đun và các phụ thuộc của nó, đó là Kiến trúc. Không có cách nào trong Java (ít nhất là cho đến Java 7) để ánh xạ một mô-đun (một bộ các gói) thành một cấu trúc cú pháp. Bạn cũng có thể nhận thấy rằng sơ đồ này thể hiện một bước cao hơn về mức độ trừu tượng của mô hình phần mềm của bạn. Bất kỳ sơ đồ nào ở trên (thô hơn so với) một sơ đồ gói, thể hiện một khung nhìn Kiến trúc khi phát triển bằng ngôn ngữ lập trình Java. Mặt khác, nếu bạn đang phát triển trong Modula-2, thì, sơ đồ mô-đun đại diện cho Thiết kế.

(Một đoạn từ http://www.copypasteisforword.com/notes/software-arch architecture-vs-software-design )

Cá nhân, tôi thích cái này:

"Nhà thiết kế quan tâm đến những gì xảy ra khi người dùng nhấn nút và kiến ​​trúc sư quan tâm đến những gì xảy ra khi mười nghìn người dùng nhấn nút."

Hướng dẫn nghiên cứu SCEA cho Java ™ EE của Mark Cade và Humphrey Sheil

Tôi đồng ý với nhiều lời giải thích; về cơ bản chúng tôi đang nhận ra sự khác biệt giữa thiết kế kiến ​​trúc và thiết kế chi tiết của các hệ thống phần mềm.

Trong khi mục tiêu của nhà thiết kế là chính xác và cụ thể trong các thông số kỹ thuật vì nó sẽ cần thiết cho sự phát triển; kiến trúc sư về cơ bản nhằm mục đích xác định cấu trúc và hành vi toàn cầu của hệ thống theo yêu cầu thiết kế chi tiết để bắt đầu.

Một kiến ​​trúc sư giỏi sẽ ngăn chặn các thông số kỹ thuật siêu cao - kiến ​​trúc không được chỉ định quá mức nhưng vừa đủ, các quyết định (kiến trúc) được thiết lập chỉ dành cho các khía cạnh gây ra rủi ro tốn kém nhất để xử lý và cung cấp một khung ("tính phổ biến") trong đó thiết kế chi tiết có thể được làm việc dựa trên sự thay đổi cho chức năng địa phương.

Thật vậy, quy trình kiến ​​trúc hoặc vòng đời chỉ tuân theo chủ đề này - mức độ trừu tượng thích hợp để phác thảo cấu trúc cho các yêu cầu kinh doanh quan trọng (về mặt kiến ​​trúc) và để lại nhiều chi tiết hơn cho giai đoạn thiết kế để cung cấp cụ thể hơn.

Kiến trúc là thiết kế, nhưng không phải tất cả thiết kế là kiến ​​trúc. Do đó, nói đúng ra, sẽ có ý nghĩa hơn khi cố gắng phân biệt giữa thiết kế kiến ​​trúc và thiết kế phi kiến ​​trúc . Và sự khác biệt là gì? Nó phụ thuộc! Mỗi kiến ​​trúc sư phần mềm có thể có một câu trả lời khác nhau (ymmv!). Chúng tôi phát triển các heuristic để đưa ra câu trả lời, chẳng hạn như 'sơ đồ lớp là kiến ​​trúc và sơ đồ trình tự là thiết kế'. Xem sách DSA để biết thêm.

Người ta thường nói rằng kiến ​​trúc ở mức độ trừu tượng cao hơn thiết kế, hoặc kiến ​​trúc là logic và thiết kế là vật lý. Nhưng khái niệm này, mặc dù thường được chấp nhận, trong thực tế là vô dụng. Nơi nào bạn vẽ ranh giới giữa trừu tượng cao hay thấp, giữa logic và vật lý? Nó phụ thuộc!

Vì vậy, đề nghị của tôi là:

• tạo một tài liệu thiết kế duy nhất.
• Đặt tên cho tài liệu thiết kế này theo cách bạn muốn hoặc, tốt hơn, theo cách người đọc quen thuộc hơn. Ví dụ: "Kiến trúc phần mềm", "Đặc tả thiết kế phần mềm".
• chia tài liệu này thành các chế độ xem và lưu ý rằng bạn có thể tạo chế độ xem dưới dạng sàng lọc của chế độ xem khác.
• làm cho các khung nhìn trong tài liệu có thể điều hướng bằng cách thêm các tham chiếu chéo hoặc siêu liên kết
• sau đó, bạn sẽ có các chế độ xem cao hơn hiển thị tổng quan rộng nhưng nông về thiết kế và các chế độ xem gần triển khai hơn hiển thị các chi tiết thiết kế hẹp nhưng sâu hơn.
• bạn có thể muốn xem một ví dụ về tài liệu kiến ​​trúc nhiều chế độ xem ( tại đây ).

Đã nói tất cả những điều đó ... một câu hỏi phù hợp hơn chúng ta cần đặt ra là: thiết kế bao nhiêu là đủ? Đó là, khi nào tôi nên ngừng mô tả thiết kế (trong sơ đồ hoặc văn xuôi) và nên chuyển sang viết mã?

Đúng là âm thanh đúng với tôi. Thiết kế là những gì bạn sẽ làm và kiến ​​trúc là cách mà các bit và phần của thiết kế sẽ được nối với nhau. Nó có thể là ngôn ngữ bất khả tri, nhưng thông thường sẽ chỉ định các công nghệ sẽ được sử dụng, ví dụ LAMP v Windows, Web Service v RPC.

Kiến trúc phần mềm của một chương trình hoặc hệ thống máy tính là cấu trúc hoặc cấu trúc của hệ thống, bao gồm các thành phần phần mềm, các thuộc tính hiển thị bên ngoài của các thành phần đó và các mối quan hệ giữa chúng.

(từ Wikipedia, http://en.wikipedia.org/wiki/Software_arch architecture )

Thiết kế phần mềm là một quá trình giải quyết vấn đề và lập kế hoạch cho một giải pháp phần mềm. Sau khi mục đích và thông số kỹ thuật của phần mềm được xác định, các nhà phát triển phần mềm sẽ thiết kế hoặc thuê các nhà thiết kế để phát triển một kế hoạch cho một giải pháp. Nó bao gồm các vấn đề triển khai thành phần và thuật toán cấp thấp cũng như chế độ xem kiến ​​trúc.

(từ Wikipedia, http://en.wikipedia.org/wiki/Software_design )

Không thể nói nó tốt hơn bản thân mình :)

Tôi xem kiến ​​trúc như Patrick Karcher - bức tranh lớn. Ví dụ: bạn có thể cung cấp kiến ​​trúc cho một tòa nhà, xem hỗ trợ cấu trúc của nó, cửa sổ, lối vào và lối ra, thoát nước, v.v. Nhưng bạn chưa "thiết kế" bố trí sàn, vị trí hình khối, v.v.

Vì vậy, trong khi bạn đã kiến ​​trúc tòa nhà, bạn chưa thiết kế bố trí của từng văn phòng. Tôi nghĩ điều tương tự cũng đúng với phần mềm.

Bạn có thể xem thiết kế bố cục, như "kiến trúc bố cục" mặc dù ...

Câu hỏi hay ... Mặc dù ranh giới giữa chúng hầu như không phải là một đường sắc nét, nhưng imho, nếu bạn đang sử dụng cả hai thuật ngữ, thì Kiến trúc bao gồm nhiều quyết định về kỹ thuật hoặc cấu trúc hơn về cách xây dựng hoặc xây dựng một cái gì đó, đặc biệt là những quyết định đó sẽ khó khăn ( hoặc khó hơn) để thay đổi một khi đã được triển khai, trong khi Thiết kế bao gồm các quyết định dễ thay đổi sau này (như tên phương thức, lớp <-> cấu trúc tổ chức tệp, các mẫu thiết kế, nên sử dụng một singleton hay một lớp tĩnh để giải quyết một số vấn đề cụ thể , v.v.) và / hoặc những thứ ảnh hưởng đến diện mạo hoặc các khía cạnh thẩm mỹ của một hệ thống hoặc ứng dụng (Giao diện con người, dễ sử dụng, nhìn và cảm nhận, v.v.)

Kiến trúc phần mềm có liên quan đến các vấn đề ... ngoài các thuật toán và cấu trúc dữ liệu của tính toán.

Kiến trúc đặc biệt không phải là về chi tiết triển khai (ví dụ: thuật toán và cấu trúc dữ liệu.) Thiết kế kiến ​​trúc bao gồm một bộ sưu tập trừu tượng phong phú hơn so với thông thường được cung cấp bởi OOD Điên (thiết kế hướng đối tượng).

Thiết kế liên quan đến việc mô đun hóa và giao diện chi tiết của các yếu tố thiết kế, thuật toán và quy trình của chúng và các loại dữ liệu cần thiết để hỗ trợ kiến ​​trúc và để đáp ứng các yêu cầu.

Kiến trúc của người Miêu thường được sử dụng như một từ đồng nghĩa với thiết kế của nhà vua (đôi khi đi trước với tính từ cấp độ cao). Và nhiều người sử dụng thuật ngữ mô hình kiến ​​trúc trên nền tảng của người dùng như một từ đồng nghĩa với các mẫu thiết kế của thành phố.

Kiểm tra liên kết này.

Xác định các Điều khoản Kiến trúc, Thiết kế và Triển khai

Kiến trúc:
Thiết kế kết cấu làm việc ở mức độ trừu tượng cao hơn, đáp ứng các yêu cầu quan trọng về mặt kỹ thuật trong hệ thống. Các kiến ​​trúc đặt nền tảng cho thiết kế hơn nữa.

Thiết kế:
Nghệ thuật điền vào những gì kiến ​​trúc không thông qua một quá trình lặp lại ở mỗi lớp trừu tượng.

Tôi thực sự thích bài viết này về quy tắc ngón tay cái trong việc tách biệt kiến ​​trúc khỏi thiết kế:

http://www.eden-study.org/articles/2006/abstraction-groupes-sw-design_ieesw.pdf

Nó được gọi là giả thuyết Intension / Locality. Các tuyên bố về bản chất của phần mềm không phải là cục bộ và cường độ cao là kiến ​​trúc. Báo cáo là địa phương và nội bộ là thiết kế.

... từ lâu ở một nơi xa xôi, các nhà triết học lo lắng về sự phân biệt giữa một và nhiều người. Kiến trúc là về mối quan hệ, đòi hỏi nhiều. Kiến trúc có các thành phần. Thiết kế là về nội dung, đòi hỏi một. Thiết kế có tính chất, phẩm chất, đặc điểm. Chúng tôi thường nghĩ rằng thiết kế là trong kiến ​​trúc. Tư duy nhị nguyên cho nhiều người như nguyên thủy. Nhưng kiến ​​trúc cũng nằm trong thiết kế. Đó là tất cả cách chúng ta chọn để xem những gì trước mắt chúng ta - một hoặc nhiều.

Khá chủ quan nhưng tôi mất:

Kiến trúc Thiết kế tổng thể của hệ thống bao gồm các tương tác với các hệ thống khác, yêu cầu phần cứng, thiết kế thành phần tổng thể và luồng dữ liệu.

Thiết kế Tổ chức và lưu lượng của một thành phần trong hệ thống tổng thể. Điều này cũng sẽ bao gồm API của thành phần để tương tác với các thành phần khác.

Kiến trúc phần mềm được sử dụng tốt nhất ở cấp hệ thống, khi bạn cần dự án kinh doanh và các chức năng xác định theo cấp kiến ​​trúc cao hơn vào các ứng dụng.

Chẳng hạn, doanh nghiệp của bạn là về "Lợi nhuận và thua lỗ" cho các nhà giao dịch và các chức năng chính của bạn liên quan đến "đánh giá danh mục đầu tư" và "tính toán rủi ro".

Nhưng khi một Kiến trúc sư phần mềm sẽ trình bày chi tiết về giải pháp của mình, anh ta sẽ nhận ra rằng:

"Đánh giá danh mục đầu tư" không thể chỉ là một ứng dụng. Nó cần được tinh chỉnh trong các dự án có thể quản lý như:

• GUI
• Trình khởi chạy
• Điều phối
• ...

(vì các hoạt động liên quan rất lớn nên chúng cần được phân chia giữa nhiều máy tính, trong khi vẫn được theo dõi mọi lúc thông qua GUI chung)

một thiết kế phần mềm sẽ kiểm tra các ứng dụng khác nhau, mối quan hệ kỹ thuật và các thành phần phụ bên trong của chúng.
Nó sẽ tạo ra các thông số kỹ thuật cần thiết cho lớp Kiến trúc cuối cùng ("Kiến trúc kỹ thuật") để hoạt động (về mặt khung kỹ thuật hoặc các thành phần chuyển đổi) và cho các nhóm dự án (định hướng hơn về việc triển khai các chức năng kinh doanh ) để bắt đầu dự án tương ứng của họ.

nếu ai đó chế tạo một con tàu, thì động cơ, thân tàu, mạch điện, v.v. sẽ là "yếu tố kiến ​​trúc" của anh ta. Đối với ông, động cơ xây dựng sẽ là "công việc thiết kế".

Sau đó, nếu anh ta ủy thác việc xây dựng động cơ cho một đội khác, họ sẽ tạo ra một "kiến trúc động cơ" ...

Vì vậy - nó phụ thuộc vào mức độ trừu tượng hoặc chi tiết. Kiến trúc của một người có thể là thiết kế của bà mẹ!

Kiến trúc là "những quyết định thiết kế khó thay đổi."

Sau khi làm việc với TDD, điều này thực tế có nghĩa là thiết kế của bạn thay đổi liên tục, tôi thường thấy mình phải vật lộn với câu hỏi này. Định nghĩa trên được trích từ Mẫu kiến ​​trúc ứng dụng doanh nghiệp , của Martin Fowler

Điều đó có nghĩa là kiến ​​trúc phụ thuộc vào Ngôn ngữ, Khung và Miền của hệ thống của bạn. Nếu bạn chỉ có thể trích xuất một giao diện từ Lớp Java của mình trong 5 phút thì đó không còn là quyết định kiến ​​trúc nữa.

Phiên bản Cliff Notes:

Thiết kế: Thực hiện một giải pháp dựa trên các thông số kỹ thuật của sản phẩm mong muốn.

Kiến trúc: Nền tảng / công cụ / cơ sở hạ tầng / thành phần hỗ trợ thiết kế của bạn.

Đây là một câu hỏi khá rộng sẽ thu hút rất nhiều câu trả lời.

Kiến trúc là tập hợp kết quả của các mẫu thiết kế để xây dựng một hệ thống.

Tôi đoán Thiết kế là sự sáng tạo được sử dụng để đặt tất cả những thứ này lại với nhau?

Thiết kế phần mềm có một lịch sử lâu dài hơn trong khi thuật ngữ kiến ​​trúc phần mềm chỉ mới 20 năm. Do đó, nó đang trải qua những cơn đau ngày càng tăng ngay bây giờ.

Giới học thuật có xu hướng xem Kiến trúc là một phần của lĩnh vực thiết kế phần mềm lớn hơn. Mặc dù ngày càng có nhiều sự công nhận rằng Arch là một lĩnh vực trong chính nó.

Các học viên có xu hướng xem Arch là các quyết định thiết kế cấp cao mang tính chiến lược và có thể tốn kém trong một dự án để hoàn tác.

Dòng chính xác giữa Arch và thiết kế phụ thuộc vào miền phần mềm. Ví dụ, trong miền Ứng dụng web, kiến ​​trúc phân lớp đang trở nên phổ biến nhất hiện nay (Lớp logic Logic, Lớp truy cập dữ liệu, v.v.) Các phần cấp thấp hơn của Arch này được coi là thiết kế (sơ đồ lớp, chữ ký phương thức, v.v. ) Điều này sẽ được định nghĩa khác nhau trong các lĩnh vực của hệ thống nhúng, hệ điều hành, trình biên dịch, v.v.

Kiến trúc là cấp cao, thiết kế trừu tượng và logic trong khi thiết kế phần mềm là cấp thấp, thiết kế chi tiết và vật lý.

Ngoài ra, hãy tham khảo: http://en.wikipedia.org/wiki/4%2B1_Arch Architectural_View_Model

Tôi thích định nghĩa và giải thích của Roy Thomas Fielding về kiến ​​trúc phần mềm trong bài viết của mình: Phong cách kiến ​​trúc và Thiết kế Kiến trúc phần mềm dựa trên mạng

Kiến trúc phần mềm là sự trừu tượng hóa các yếu tố thời gian chạy của hệ thống phần mềm trong một số giai đoạn hoạt động của nó. Một hệ thống có thể bao gồm nhiều mức độ trừu tượng và nhiều giai đoạn hoạt động, mỗi giai đoạn có kiến ​​trúc phần mềm riêng.

Ông nhấn mạnh "các yếu tố thời gian chạy" và "mức độ trừu tượng".

Không có câu trả lời dứt khoát cho vấn đề này bởi vì "kiến trúc phần mềm" và "thiết kế phần mềm" có khá nhiều định nghĩa và không có định nghĩa chính tắc nào cho cả hai.

Một cách nghĩ tốt về nó là Len Bass, Paul Clements và Rick Kazman tuyên bố rằng "tất cả kiến ​​trúc là thiết kế nhưng không phải tất cả thiết kế đều là kiến ​​trúc" [Kiến trúc phần mềm trong thực tế]. Tôi không chắc là tôi hoàn toàn đồng ý với điều đó (vì kiến ​​trúc có thể bao gồm các hoạt động khác) nhưng nó nắm bắt được bản chất rằng kiến ​​trúc là một hoạt động thiết kế liên quan đến tập hợp con quan trọng của thiết kế.

Định nghĩa hơi thiếu sót của tôi (tìm thấy trên trang định nghĩa SEI ) là tập hợp các quyết định mà nếu đưa ra sai, khiến dự án của bạn bị hủy bỏ.

Một nỗ lực hữu ích trong việc phân tách kiến ​​trúc, thiết kế và triển khai như các khái niệm đã được Amnon Eden và Rick Kazman thực hiện vài năm trước trong một bài viết nghiên cứu có tên "Kiến trúc, thiết kế, triển khai" có thể tìm thấy ở đây: http: //www.sei.cmu .edu / thư viện / tài sản / ICSE03-1.pdf . Ngôn ngữ của họ khá trừu tượng nhưng đơn giản họ nói rằng kiến trúc là thiết kế có thể được sử dụng trong nhiều bối cảnh và được áp dụng trên toàn hệ thống, thiết kế là thiết kế (err) có thể được sử dụng trong nhiều bối cảnh nhưng được áp dụng trong một phần cụ thể của hệ thống và thực hiện là thiết kế cụ thể cho một bối cảnh và được áp dụng trong bối cảnh đó.

Vì vậy, một quyết định kiến ​​trúc có thể là một quyết định tích hợp hệ thống thông qua tin nhắn chứ không phải RPC (vì vậy đó là một nguyên tắc chung có thể được áp dụng ở nhiều nơi và dự định áp dụng cho toàn hệ thống), quyết định thiết kế có thể là sử dụng chính / cấu trúc luồng nô lệ trong mô đun xử lý yêu cầu đầu vào của hệ thống (một nguyên tắc chung có thể được sử dụng ở bất cứ đâu nhưng trong trường hợp này chỉ được sử dụng trong một mô-đun) và cuối cùng, quyết định thực hiện có thể là chuyển trách nhiệm bảo mật từ Bộ định tuyến yêu cầu đến Trình xử lý yêu cầu trong mô-đun Trình quản lý yêu cầu (một quyết định chỉ liên quan đến bối cảnh đó, được sử dụng trong ngữ cảnh đó).

Tôi hi vọng cái này giúp được!