Làm thế nào để tôi ngừng thiết kế và bắt đầu kiến ​​trúc dự án này theo đề xuất của lãnh đạo của tôi? [đóng cửa]

Tôi là một nhà phát triển cơ sở (~ 3 năm kinh nghiệm) và trong công việc của mình, chúng tôi đang trong quá trình kiến ​​trúc một hệ thống mới. Nhà phát triển chính của tôi sẽ là kiến ​​trúc sư chính, tuy nhiên anh ấy đã thách thức tôi thử tự mình thiết kế hệ thống (song song).

Trải qua một vài lần lặp lại ý tưởng và đề xuất những gì tôi thấy là đề xuất kiến ​​trúc, sự dẫn dắt của tôi đã cho tôi phản hồi rằng hầu hết những gì tôi đang làm là "thiết kế" chứ không phải "kiến trúc".

Ông mô tả sự khác biệt khi kiến ​​trúc là bất khả tri trong khi thiết kế là mô tả của việc thực hiện. Anh ấy nói tôi cần phải cởi mũ thiết kế của tôi và đội mũ kiến ​​trúc sư của tôi. Anh ấy đã cho tôi một lời khuyên nhỏ về cách làm như vậy, nhưng tôi cũng muốn hỏi bạn:

Làm cách nào để thoát khỏi chế độ thiết kế phần mềm và bắt đầu suy nghĩ giống một kiến ​​trúc sư hơn?

Dưới đây là một số ví dụ về "thiết kế" mà tôi đã đưa ra mà không được xem là có liên quan đến kiến ​​trúc bởi sự dẫn dắt của tôi:

1. Tôi đã đưa ra một thuật toán để tải và dỡ tài nguyên từ hệ thống của chúng tôi và khách hàng tiềm năng của tôi nói rằng các thuật toán này không phải là kiến ​​trúc.
2. Tôi đã đưa ra một tập hợp các sự kiện mà hệ thống sẽ đưa ra và theo thứ tự nó sẽ nâng chúng lên, nhưng điều này dường như cũng không cắt nó thành kiến ​​trúc.

Tôi dường như bị cuốn vào các chi tiết và không lùi bước đủ xa. Tôi thấy rằng ngay cả khi tôi nghĩ ra thứ gì đó ở cấp độ kiến ​​trúc, tôi vẫn thường đến đó bằng cách thử nhiều cách triển khai khác nhau và tìm hiểu chi tiết sau đó khái quát hóa và trừu tượng hóa. Khi tôi mô tả điều này với sự dẫn dắt của mình, anh ấy nói rằng tôi đã sử dụng sai phương pháp: tôi cần phải suy nghĩ "từ trên xuống" chứ không phải "từ dưới lên".

Dưới đây là một số chi tiết cụ thể hơn về dự án :

• Dự án chúng tôi đang kiến ​​trúc là một ứng dụng web.
• Tôi đang ước tính khoảng 10 - 100 nghìn dòng mã.
• Chúng tôi là một khởi đầu. Đội ngũ kỹ thuật của chúng tôi có khoảng 3-5 người.
• Điều gần nhất tôi có thể so sánh ứng dụng của chúng tôi là một CMS nhẹ. Nó có độ phức tạp tương tự và chủ yếu liên quan đến tải và dỡ thành phần, quản lý bố cục và mô-đun kiểu trình cắm.
• Ứng dụng này là ajax-y. Người dùng tải xuống máy khách một lần sau đó yêu cầu dữ liệu vì nó cần nó từ máy chủ.
• Chúng tôi sẽ sử dụng mô hình MVC.
• Ứng dụng sẽ có xác thực.
• Chúng tôi không quan tâm lắm đến việc hỗ trợ trình duyệt cũ (whew!), Vì vậy chúng tôi đang tìm cách tận dụng những thứ mới nhất và tốt nhất hiện có và sẽ ra mắt. (HTML5, CSS3, WebGL?, Tiện ích mở rộng nguồn phương tiện và hơn thế nữa!)

Dưới đây là một số mục tiêu của dự án :

• Các ứng dụng cần phải mở rộng quy mô. Trong thời gian tới, người dùng của chúng tôi sẽ có thứ tự từ hàng trăm đến hàng nghìn, nhưng chúng tôi đang lên kế hoạch cho hàng chục nghìn đến hàng triệu và hơn thế nữa.
• Chúng tôi hy vọng ứng dụng sẽ tồn tại mãi mãi. Đây không phải là một giải pháp tạm thời. (Trên thực tế chúng tôi đã có một giải pháp tạm thời và những gì chúng tôi đang kiến ​​trúc là sự thay thế lâu dài cho những gì chúng tôi có).
• Ứng dụng nên được bảo mật vì nó có thể có liên hệ với thông tin cá nhân nhạy cảm.
• Ứng dụng cần phải ổn định. (Lý tưởng nhất là nó sẽ ổn định ở mức độ của gmail nhưng nó không cần phải ở mức cực đoan của người đi trên sao Hỏa.)

Trước hết tôi muốn nói rằng sự khác biệt giữa kiến ​​trúc và thiết kế chủ yếu là ngữ nghĩa. Một số đội có điểm kiểm tra giữa hai. Lãnh đạo kỹ thuật của bạn xác định kiến ​​trúc như trước khi thiết kế và kiến ​​trúc là thuyết bất khả tri. Từ đó tôi giả sử chúng ta đang nói về thiết kế như trong mô hình thác nước chứ không phải Thiết kế công nghiệp sẽ giúp bạn thiết kế sản phẩm với tầm nhìn cho người dùng trước khi bạn tiếp cận kiến ​​trúc phần mềm. Tôi nghĩ kiến ​​trúc thường trượt vào thiết kế và đó không hẳn là một điều xấu, nó thường rất hữu ích cho kiến ​​trúc sư để có kiến ​​thức sâu sắc về những gì có thể có trong hệ thống.

Đã nói tất cả, bạn cần một số lời khuyên cho tình huống bạn đang gặp phải. Có cả một thế giới kiến ​​trúc phần mềm ngoài kia, giấy tờ, sách, hội nghị nhưng bạn thường tìm kiếm các mẫu và trừu tượng. Không có thêm chi tiết về dự án tôi chỉ có thể đưa ra một ví dụ rộng. Chẳng hạn, nếu bạn đang làm việc trong tích hợp thì có Kiến trúc hướng dịch vụ ( SOA) mẫu mà bạn chia các phần của hệ thống thành 'dịch vụ' để bạn có thể làm việc với từng phần theo cách xác định, trong chương trình web, điều này thường được triển khai dưới dạng Dịch vụ web (mặc dù không nên giới hạn ở điều đó) và gần đây hơn là sự nổi lên của các API RESTful với JSON, một lần nữa tôi sẽ nói rằng đây là một thiết kế đến từ kiến ​​trúc của SOA. Tôi muốn nói Model, View, Controller (MVC) là một ví dụ khác về mẫu kiến ​​trúc được sử dụng phổ biến, phân chia trách nhiệm của các thành phần của hệ thống để cho phép các bộ phận được hoán đổi, để chứa lỗi và kiểm tra.

Từ mức 10.000ft, nếu bạn có thể vẽ nó trên bảng trắng và giải thích nó cho một lập trình viên có năng lực, người không làm việc trong lĩnh vực của bạn và không biết ngôn ngữ lập trình và chi tiết triển khai hiện tại thì đó có thể là kiến ​​trúc. Nếu bạn có thể viết một cuốn sách về nó mà bất cứ ai ngoài công ty của bạn sẽ quan tâm thì đó có lẽ là kiến ​​trúc. Nếu bạn thấy chi tiết tự giải thích của mình và không thể khái quát nó cho các cơ sở / công ty / ngành công nghiệp mã khác thì đó có thể là thiết kế.

Tôi đồng ý rằng hai ví dụ bạn đưa ra là thiết kế mã chứ không phải kiến ​​trúc. Đầu tiên bởi vì tôi nghĩ khi bạn nói rằng bạn đã đưa ra một 'thuật toán' để tải tài nguyên Tôi nghĩ bạn có nghĩa là bạn đã thiết kế một bộ hướng dẫn để thực hiện nhiệm vụ đó, và không phải là bạn đã thiết kế một thuật toán mới mà họ sẽ dạy trong năm đầu tiên COMSC vào năm tới. Trong ví dụ thứ hai, một lần nữa tôi đồng ý đó là thiết kế. Nếu bạn chỉ cho tôi một trong những ý tưởng này, tôi sẽ không thể sử dụng chúng trong dự án phần mềm ngẫu nhiên của mình. Bạn phải đi đến 'cấp độ cao hơn', hướng đối tượng (OO) trong Java chứ không phải tôi muốn Lớp khách hàng là lớp con của Lớp người. Ngay cả việc nói về Ngoại lệ nói chung cũng có thể được coi là mức độ quá thấp (quá gần với việc thực hiện).

Để cố gắng giải quyết các chi tiết cụ thể mà bạn liệt kê, tôi nghĩ điều bạn nên nghĩ đến là làm thế nào để kiến ​​trúc một CMS dựa trên web. Wordpress có một bộ mã kiến ​​trúc trang web nơi họ nói rất nhiều về các chi tiết triển khai thiết kế nhưng rõ ràng từ bài đăng rằng kiến ​​trúc chính của họ xoay quanh việc làm cho Wordpress có thể mở rộng với các chủ đề. Kiến trúc một giao diện rõ ràng cho một chủ đề sao cho nó có thể được viết bởi một người bên ngoài công ty rõ ràng là một quyết định kiến ​​trúc mà họ đã đưa ra. Đây là những điều tốt để có được trên giấy khi kiến ​​trúc giải pháp 'dài hạn' (không phải tạm thời) của bạn để tất cả các quyết định thiết kế và thực hiện được đưa ra trong quá trình phát triển (bởi tất cả các nhà phát triển không chỉ là kiến ​​trúc sư) phù hợp với ý tưởng này.

Các ví dụ khác về kiến ​​trúc cho tình huống của bạn:

1. Đưa toàn bộ vào máy ảo, được lưu trữ trên nhà cung cấp đám mây hoặc tại nhà và có các trường hợp máy không trạng thái, để mọi máy bị lỗi có thể được thay thế bằng một phiên bản mới của máy ảo mà không phải sao chép qua bất kỳ trạng thái nào hoặc mất bất kỳ thông tin nào.
2. Xây dựng trong thử nghiệm thất bại sản xuất trực tiếp từ đầu với simian hỗn loạn .

Có thể thử vẽ toàn bộ hệ thống trên một bảng trắng. Hãy thử nó ở các mức độ chi tiết khác nhau, bảng đầu tiên có thể là GUI-> bộ điều phối-> phụ trợ-> DB hoặc một cái gì đó, sau đó đi sâu vào cho đến khi bạn bắt đầu sử dụng đại từ.

Sự khác biệt giữa hai ý tưởng này thực sự quan trọng ở nơi tôi làm việc.

Những gì bạn gọi là "kiến trúc", chúng tôi gọi là "lập trình bằng tiếng Anh." Điều này một phần quan trọng bởi vì nếu bạn không thể mô tả nó cho một người không lập trình, thì có gì đó không ổn. Có thể là bạn không hiểu rõ vấn đề đủ, HOẶC có thể là bạn đang giải quyết vấn đề "ảo" (không được thảo luận ở đây).

Các thuật ngữ được sử dụng cho hai khía cạnh khác nhau của thiết kế thường khác nhau, nhưng các nguyên tắc dễ dàng được nhận ra ở mọi nơi. Một khía cạnh (trong trường hợp của bạn là kiến ​​trúc sư, trong trường hợp của tôi là nhà thiết kế) các chương trình bằng tiếng Anh, trong khi khía cạnh khác (trong trường hợp của bạn là "nhà thiết kế", trong trường hợp của tôi là "nhà phát triển") trong một ngôn ngữ cụ thể. Họ cũng khá phổ biến được phân biệt là "thiết kế" và "thực hiện." "Thiết kế" là những gì nó phải hoàn thành và "triển khai" là mã làm cho nó xảy ra.

Một số ví dụ từ những gì tôi đã làm việc trên:

Kiến trúc của một chương trình là: chúng ta cần một Trình quản lý tập trung hoặc trung tâm mà chúng ta có thể dễ dàng thêm các mô-đun vào. Trình quản lý này sẽ phân phối các sự kiện cho tất cả các mô-đun đã đăng ký. Một mô-đun có thể tự đăng ký với Trình quản lý sự kiện và từ đó xuất bản các sự kiện cho phần còn lại của hệ thống và nhận các sự kiện mà nó quan tâm. Mỗi mô-đun có một "hộp thư" mà nó có thể kiểm tra và làm trống tùy thích. Điều này sẽ cho phép chúng tôi chứa các mô-đun mới mà chúng tôi chưa biết chúng tôi cần.

Không có mã ở đó. Có thể được viết bằng bất kỳ ngôn ngữ nào. Việc thực hiện không được quyết định bởi mô tả này.

Kiến trúc của một dự án khác là: chúng ta cần một cách đáng tin cậy để bắt đầu và dừng các chương trình khác mà không cần chờ đợi chúng. Chúng tôi có thể có một người quản lý chịu trách nhiệm cho một chương trình cụ thể. Chúng tôi chỉ có thể bảo nó bắt đầu hoặc dừng chương trình của nó và người quản lý sẽ chăm sóc nó. Nếu chương trình khác này được yêu cầu dừng và không trong một khoảng thời gian nhất định, người quản lý sẽ biết cách buộc chương trình dừng lại và dọn dẹp mớ hỗn độn. Chương trình không được bắt đầu hoặc dừng bởi bất kỳ điều gì khác, và người quản lý có thể được hỏi liệu chương trình của nó đang chạy, dừng hay chờ dừng. Điều này cho phép chúng tôi tiếp tục với những điều khác mà chúng tôi cần phải làm, trong khi vẫn bắt đầu các chương trình khác này và dừng lại đúng cách.

Một lần nữa, không có gì ở đây chỉ ra việc thực hiện, mặc dù một số triển khai rõ ràng hữu ích hơn những thứ khác.

Sự khác biệt giữa thiết kế (cái mà chúng ta gọi là mẫu hoặc triển khai) và kiến ​​trúc (cái mà chúng ta gọi là thiết kế) là một trong số chúng giải quyết vấn đề mã hóa / triển khai và cái còn lại giải quyết vấn đề trong thế giới thực.

Có thể điều này sẽ giúp. Tôi luôn thấy thâm niên của một kỹ sư là một câu hỏi về vấn đề lớn mà họ có thể tự giải quyết.

Roughly, để truyền đạt ý tưởng:

• Bạn có thể cung cấp cho ai đó mới để lập trình các tác vụ nhỏ, chứa nhiều hướng dẫn rõ ràng về cách nhiệm vụ cần tích hợp với các phần khác

• Một nhà phát triển cấp trung là người có thể mô tả một phần của ứng dụng và làm cho nó hoạt động trong bối cảnh của ứng dụng đó.

• Một nhà phát triển cao cấp có thể xây dựng một ứng dụng cỡ trung bình từ đầu, trong các hạn chế kỹ thuật của một cửa hàng.

• Một nhà phát triển cao cấp hơn có thể làm điều đó, và đưa ra lựa chọn công nghệ trên đường đi về việc sử dụng công nghệ nào để làm cho nó hoạt động tốt.

... nhưng đó không phải là những quy tắc khó và nhanh. Và một số người bước ra khỏi cổng với tư cách là IMHO "cao cấp", ngay cả khi họ phải dành thời gian với một tiêu đề khác.

Những gì kiến ​​trúc sư đang yêu cầu là xem vấn đề thậm chí còn hơn thế. Nếu bạn phải kết hợp một số ứng dụng để làm cho hệ thống hoạt động:

• Những ứng dụng và dịch vụ nào bạn sẽ cần?
• Những mảnh nào tương tác với khách hàng, và những phần tương tác với nhau?
• Họ sẽ giao tiếp như thế nào?
• Họ sẽ lưu trữ dữ liệu ở đâu?
• Đâu là rủi ro thất bại?
• Làm thế nào bạn sẽ cung cấp độ tin cậy?
• Làm thế nào bạn sẽ cung cấp bảo mật?

Vì vậy, trong một ý nghĩa kiến ​​trúc kỹ thuật giống như một kiến ​​trúc xây dựng. Đó là cách bố trí, hoặc kế hoạch. Nó cho thấy những gì cần thiết cho các bộ phận khác nhau, cách chúng giữ lại với nhau và quan trọng là tại sao .

(Si .)

Điều đó nói rằng, tôi nghĩ rằng hầu hết các kỹ sư ở tất cả các cấp cũng phải thực hiện một số "kiến trúc". Đó không phải là một đường sáng. Có vẻ như nếu bạn tập trung vào Bức tranh lớn trước và không bị gò bó về các chi tiết triển khai, bạn sẽ phù hợp hơn với những gì anh ấy đang tìm kiếm. BTW khả năng xem Bức tranh lớn cũng như các chi tiết nhỏ là một tài sản lớn trong ngành này, vì vậy đây có vẻ là một cơ hội tuyệt vời.

... Đây là một tương tự. Giả sử bạn được yêu cầu tạo Hộp đen ma thuật. Là một kỹ sư, bạn sẽ bị ám ảnh về hoạt động bên trong của Hộp đen ma thuật. Nhưng là một kiến ​​trúc sư, trọng tâm của bạn là khác nhau. Bạn có thể lén nhìn vào chiếc hộp vì tò mò, nhưng bạn sẽ bị ám ảnh về mọi thứ xung quanh tất cả các Hộp đen ma thuật.

Tương tự như sự tương tự đó, bạn có thể nghĩ về vai trò kiến ​​trúc khi xem toàn bộ hệ thống như chiếc hộp ma thuật. Vì vậy, nếu lấy Hộp kính khổng lồ và bạn đặt khách hàng, ứng dụng khách, tường lửa, tầng dịch vụ, cơ sở dữ liệu và thậm chí cả những kẻ sùng đạo bên trong, thì với tư cách là kiến ​​trúc sư bạn sẽ bị ám ảnh về cách tạo ra hộp hệ thống khổng lồ đó làm việc tốt .

Sự khác biệt chính xác giữa "thiết kế" và "kiến trúc" là một chút chủ quan và có một số chồng chéo. Tuy nhiên, đây là sự khác biệt như tôi hiểu:

Kiến trúc nhìn vào các khái niệm cấp cao. Các diễn viên trong hệ thống là ai? Các đối tượng chính và những đối tượng chịu trách nhiệm cho những gì? Khi tôi nghĩ về kiến ​​trúc, tôi nghĩ Visio, không phải mã.

Ví dụ: một hệ thống sự kiện có thể có một người quản lý sự kiện chấp nhận các sự kiện đến và gửi chúng đến các bộ xử lý sự kiện. Ý tưởng về các chủ đề, không đồng bộ v. Đồng bộ và các khái niệm cấp thấp khác không xuất hiện ở đây. MVC là một ví dụ khác: chi tiết cụ thể không được chỉ định ở mức cao về cách ba phần tương tác, chỉ có ba mối quan tâm riêng biệt được xử lý bởi các gói mã riêng biệt.

Thiết kế bao gồm tạo mẫu, phác thảo ra các giao diện mã, bộ xương mã, v.v ... Nó nằm giữa kiến ​​trúc trừu tượng và công việc "khỉ mã" cấp thấp.

Trong khung sự kiện, thiết kế có thể nói "một sự kiện sử dụng giao diện này" và "có một nhóm luồng mà người quản lý sự kiện sử dụng để gửi các sự kiện tới công nhân." Một thiết kế cho MVC có thể là "sử dụng Hibernate cho mô hình, Spring cho bộ điều khiển và GWT cho chế độ xem."

Khi tôi làm công việc thiết kế, tôi đã phác thảo ra các giao diện và bộ xương mã, sau đó đưa ra kết quả cho các lập trình viên. Đôi khi tôi là lập trình viên đó. Nhưng đó là hai giai đoạn riêng biệt và cả hai đều tồn tại về phía bê tông hơn là kiến ​​trúc.

Đặt mũ kiến ​​trúc có nghĩa là làm rõ tâm trí của bạn về mã và suy nghĩ các đối tượng trên bảng trắng. Hãy suy nghĩ các đối tượng, gói, khung và luồng thông điệp giữa chúng. Nếu bạn đang nghĩ về ngay cả một dòng mã bạn đang làm sai. Đừng sa lầy vào một cái gì đó như "oh, tin nhắn đó có thể là một chuỗi, hoặc sử dụng SOAP, hoặc bất cứ điều gì." Ở cấp độ này, thực tế là giao tiếp đang xảy ra là đủ. Chi tiết không liên quan.

Nếu tôi có thể thêm bất cứ điều gì ở đây, thì đó là: đừng nghĩ mã . Ở tất cả.

Đừng nghĩ làm thế nào bạn sẽ viết mã để hoàn thành một cái gì đó, nhưng hãy nghĩ về phương pháp tốt nhất sẽ là gì để hoàn thành nó. Mô tả của bạn về những gì bạn cần làm là không biết ngôn ngữ , vì vậy bạn sẽ nói về các mẫu thiết kế - vốn là "ngôn ngữ" chung giữa những người sử dụng các ngôn ngữ lập trình khác nhau - để thảo luận về cách tiến lên.

Đối với trường hợp sử dụng cụ thể của bạn, theo tôi, nhiều câu hỏi về kiến ​​trúc sẽ nằm dọc theo dòng:

• Tại sao bạn sử dụng MVC? Có phải tất cả những gì bạn biết? Có mô hình tốt hơn để sử dụng? Tại sao?
• Khung nào bạn sẽ sử dụng, và tại sao ?
• Làm thế nào bạn sẽ quy mô? Không khôn ngoan, bởi vì điều đó chưa thành vấn đề. Điều kiện sẽ là gì để quy mô theo chiều ngang; bạn sẽ sử dụng dịch vụ nào (AWS) để làm việc này?
• Làm thế nào là xác thực sẽ được thực hiện? Không khôn ngoan về mã: bạn có đang tạo mã thông báo ngẫu nhiên, duy nhất cho mỗi yêu cầu và kiểm tra mã thông báo đó không? Đừng nghĩ làm thế nào bạn sẽ làm điều này trong mã. Hãy suy nghĩ về lý do tại sao bạn làm điều này - bởi vì điều này thực tế có thể được thực hiện trong bất kỳ ngôn ngữ web nào.

Về cơ bản, đừng nói gì về mã. Ngay cả khi bạn không biết làm gì, khi có ý chí, vẫn có cách . Hãy suy nghĩ nhiều hơn về cách các mảnh ghép sẽ khớp với nhau tốt nhất, trước khi bạn lo lắng về việc thực sự ghép chúng lại với nhau.

Hãy nghĩ về tất cả các hoạt động (ví dụ: trường hợp sử dụng) hệ thống của bạn có thể thực hiện. Đối với mỗi hoạt động, hãy ghi lại những gì xảy ra theo tên miền doanh nghiệp của bạn cho từng hoạt động. Bạn chỉ nên nói về lĩnh vực vấn đề của mình và không mô tả bất kỳ chi tiết triển khai nào. Vẽ một khối lớn và gọi nó là Hệ thống. Sự kết hợp giữa "khối lớn" này và các mô tả hoạt động là kiến ​​trúc hệ thống cấp cao nhất.

Mặc dù kiến ​​trúc cấp cao này cung cấp một điểm khởi đầu tốt, nhưng nó thực sự không có nhiều giá trị khi xây dựng một hệ thống thực tế. Bạn phải đưa nó xuống một cấp độ chi tiết để biến điều này thành một kiến ​​trúc hữu ích.

Vì vậy, bạn theo cùng một ý tưởng chung như cách tiếp cận "khối lớn" chỉ khi bạn bắt đầu thêm "khối phụ" cần thiết để thực hiện mỗi thao tác. Các "khối con" này thường được gọi là các lớp hoặc mô-đun miền. Chúng dễ dàng được xác định bằng cách sử dụng các mô tả hoạt động của bạn (từ cách tiếp cận khối lớn) và vẽ sơ đồ trình tự. Chúng được gọi là các lớp miền vì chúng không có ý định là các lớp "thực", nhưng chúng được dự định để mô tả hệ thống của bạn theo miền vấn đề của hệ thống của bạn.

Kết quả cuối cùng của việc tạo tất cả các sơ đồ trình tự và xác định tất cả các "khối con" là bây giờ bạn có một danh sách các lớp miền và danh sách các hoạt động của chúng. Điều này thường kết thúc trong một kiến ​​trúc phần mềm khá có thể sử dụng, trong đó mỗi "khối con" / mô-đun có thể được gửi đến các nhà phát triển khác nhau để thiết kế và thực hiện.

Tất nhiên, nếu bạn để nguyên như vậy, thì các nhà thiết kế của bạn sẽ có nhiều tương tác với nhau trong việc xác định giao diện giữa các mô-đun. Do đó, kiến ​​trúc sư cũng có thể quyết định các cơ chế giao diện và loại dữ liệu cụ thể sẽ được sử dụng giữa các mô-đun.

Ngoài ra, một số "khối phụ" sẽ vẫn rất phức tạp. Vì vậy, một bước lặp khác của phương pháp "khối phụ" có thể là cần thiết nhưng chỉ lần này trên một trong các mô-đun mới được xác định.

Cuối cùng, có thể có một số mẫu / giới hạn cụ thể giữa các giao diện mà kiến ​​trúc sư muốn hệ thống tuân thủ (ví dụ như gọi lại sự kiện so với gọi phương thức trực tiếp), vì vậy những quyết định đó sẽ cần được nói đến trong thiết kế kiến ​​trúc. Ngoài ra, có thể có các mô-đun "phổ biến" mà kiến ​​trúc sư muốn mọi người sử dụng.

Là một nhà phát triển, có lẽ bạn đã quen với việc cung cấp giải pháp. Đó là một cách suy nghĩ rất tốt, nhưng có thể cản trở bạn khi nghĩ về kiến ​​trúc.

Tôi thấy rằng nó giúp mô tả vấn đề mà bạn đang cố gắng giải quyết đầu tiên. Các yêu cầu là gì? Những hạn chế là gì? Bạn có thể nói chuyện với các bên liên quan để tìm hiểu những yêu cầu này?

Nó có thể hữu ích nếu bạn có thể mô tả các mục tiêu thiết kế của riêng bạn là tốt. Là giải pháp của bạn cần phải mở rộng quy mô, hoặc là một thiết kế cho một người dùng đủ? Giải pháp của bạn cần duy trì trong bao lâu? Đây có phải là một sửa chữa một lần, hoặc một giải pháp cơ sở hạ tầng dài hạn? PErinois cũng quan trọng như vậy: các giới hạn được chấp nhận của kiến ​​trúc của bạn là gì?

Và vì đây là một kinh nghiệm học tập, đừng ngại đặt câu hỏi, ngay cả khi chúng ngớ ngẩn.