Có phải Kiến trúc sạch sẽ của Martin Martin là một quy tắc chung cho tất cả các kiến ​​trúc hay nó chỉ là một trong những lựa chọn?

Tôi thực sự thích các khái niệm trong video Nguyên tắc kiến ​​trúc sạch của chú Bob Martin . Nhưng tôi cảm thấy như mẫu này giống như sự kết hợp của các mẫu Tóm tắt Factory và Builder ở cốt lõi của nó.

Đây là một cách để viết chương trình tốt nhưng không phải là cách duy nhất.

Rails và Reacjs là 2 khung xuất hiện trong tâm trí không thúc đẩy loại kiến ​​trúc sạch này. Rails hy vọng logic kinh doanh của bạn sẽ nằm trong các mô hình ( FatModels và SkinnyControllers ) và phản ứng bên trong các thành phần của bạn. Cả hai cách tiếp cận chặt chẽ logic kinh doanh và mã khung .

Tôi không tìm thấy bất cứ điều gì sai trong bất kỳ 3 cách. Đó là một cuộc gọi phán xét để chọn bất kỳ một.

Nhưng trong video tôi cảm thấy anh ấy gợi ý rằng kiến ​​trúc sạch sẽ có ranh giới rõ ràng giữa logic kinh doanh và khung. Các khung (web, android, v.v.) phải là các plugin cắm vào logic nghiệp vụ. Anh ấy thậm chí còn tinh tế chế giễu đường ray trong video.

Vì vậy, "Kiến trúc sạch" của Bob Martin có phải là một quy tắc chung cho tất cả các kiến ​​trúc hay nó chỉ là một trong những lựa chọn?

Mặc dù Kiến trúc sạch sẽ rất tốt và có nhiều ưu điểm, nhưng điều quan trọng cần nhớ là:

• Kiến trúc sạch phần lớn là tái tạo thương hiệu và sự phát triển của các phương pháp liên quan của Robert C. Martin như Jeffrey Palermo (2008) và Kiến trúc lục giác (Cổng Cổng và Bộ điều hợp thích ứng) của Alistair Cockburn và những người khác (<2008).

• Các vấn đề khác nhau có yêu cầu khác nhau. Kiến trúc sạch và các phương pháp liên quan biến sự tách rời, linh hoạt và đảo ngược phụ thuộc lên đến mười một, nhưng hy sinh sự đơn giản. Đây không phải là một thỏa thuận tốt.

Tiền thân của các kiến ​​trúc này là mô hình MVC cổ điển từ Smalltalk. Điều này loại bỏ mô hình khỏi giao diện người dùng (bộ điều khiển và khung nhìn), do đó mô hình không phụ thuộc vào giao diện người dùng. Có nhiều biến thể của MVC như MVP, MVVM, Hoài.

Các hệ thống phức tạp hơn không chỉ có một giao diện người dùng, mà có thể có nhiều giao diện người dùng. Nhiều ứng dụng chọn cung cấp API REST có thể được sử dụng bởi bất kỳ giao diện người dùng nào, chẳng hạn như ứng dụng web hoặc ứng dụng di động. Điều này tách biệt logic nghiệp vụ trên máy chủ khỏi các UI này, vì vậy máy chủ không quan tâm loại ứng dụng nào truy cập nó.

Thông thường, máy chủ vẫn phụ thuộc vào các dịch vụ phụ trợ như cơ sở dữ liệu hoặc nhà cung cấp bên thứ ba. Điều này là hoàn toàn tốt, và dẫn đến một kiến ​​trúc lớp đơn giản.

Kiến trúc lục giác đi xa hơn và ngừng phân biệt giữa frontend và backend. Bất kỳ hệ thống bên ngoài nào cũng có thể là đầu vào (nguồn dữ liệu) hoặc đầu ra. Hệ thống cốt lõi của chúng tôi xác định các giao diện (cổng) cần thiết và chúng tôi tạo bộ điều hợp cho bất kỳ hệ thống bên ngoài nào.

Một cách tiếp cận cổ điển để phân tách mạnh là kiến ​​trúc hướng dịch vụ (SOA), trong đó tất cả các dịch vụ đều xuất bản các sự kiện và tiêu thụ các sự kiện từ một bus tin nhắn được chia sẻ. Một cách tiếp cận tương tự sau đó đã được phổ biến bởi microservice.

Tất cả các cách tiếp cận này đều có những ưu điểm , chẳng hạn như giúp kiểm tra hệ thống một cách dễ dàng hơn (bằng cách thay thế tất cả các hệ thống bên ngoài mà nó giao tiếp bằng các triển khai giả). Chúng giúp dễ dàng cung cấp nhiều triển khai cho một loại dịch vụ (ví dụ: thêm bộ xử lý thanh toán thứ hai) hoặc trao đổi việc triển khai dịch vụ (ví dụ: chuyển từ cơ sở dữ liệu Oracle sang PostgreQuery hoặc bằng cách viết lại dịch vụ Python trong Go) .

Nhưng những kiến ​​trúc này là những kiến ​​trúc của Ferrari: đắt tiền và hầu hết mọi người không cần chúng. Tính linh hoạt bổ sung của Kiến trúc sạch, vv có chi phí phức tạp hơn. Nhiều ứng dụng và đặc biệt là ứng dụng web CRUD không được hưởng lợi từ đó. Thật hợp lý khi cô lập những thứ có thể thay đổi, ví dụ như bằng cách sử dụng các mẫu để tạo HTML. Nó ít có ý nghĩa hơn để cô lập những thứ không có khả năng thay đổi, ví dụ như cơ sở dữ liệu sao lưu. Những gì có khả năng thay đổi phụ thuộc vào bối cảnh và nhu cầu kinh doanh.

Các khuôn khổ đưa ra các giả định về những gì sẽ thay đổi. Ví dụ React có xu hướng cho rằng thiết kế và hành vi của một thành phần thay đổi cùng nhau, do đó không có ý nghĩa gì khi tách chúng ra. Rất ít khung cho rằng bạn có thể muốn thay đổi khung. Như vậy, các khung công tác hiện một số lượng khóa. Ví dụ, sự phụ thuộc của Rail vào mẫu Bản ghi hoạt động (rất có ý kiến!) Khiến khó có thể thay đổi chiến lược truy cập dữ liệu của bạn sang mẫu Kho lưu trữ (thường vượt trội). Nếu kỳ vọng thay đổi của bạn không phù hợp với khung, sử dụng khung khác có thể tốt hơn. Nhiều khung web khác không đưa ra bất kỳ giả định nào về việc truy cập dữ liệu.

Tôi thực sự thích các khái niệm trong video Nguyên tắc kiến ​​trúc sạch của chú Bob Martin. Nhưng tôi cảm thấy như mẫu này giống như sự kết hợp của các mẫu Tóm tắt Factory và Builder ở cốt lõi của nó.

Thậm chí không gần gũi.

Khi bạn nhìn vào điều này:

Bạn đang xem thiết kế của một đồ thị đối tượng. Điều này chỉ ra những gì biết về những gì. Điều còn thiếu trong câu chuyện này là cách đồ thị đối tượng được xây dựng. Xin lỗi nhưng bạn sẽ không tìm thấy ở đây. Không có bất kỳ đề cập đến xây dựng.

Bạn có thể xây dựng tất cả điều này mà không cần các nhà máy và nhà xây dựng trừu tượng. Tôi biết vì tôi đã làm nó . Tôi thậm chí không đặt ra để tránh chúng. Tôi yêu họ. Tôi chỉ không cần chúng. Tôi chỉ sử dụng tham khảo đi qua. Dependency Injection là thuật ngữ ưa thích cho điều đó.

Trong thực tế, tôi có thể xây dựng mọi thứ bạn thấy trong sơ đồ đó trong chính. Sau đó, chỉ cần gọi một phương thức trên một đối tượng để bắt đầu đánh dấu toàn bộ.

Bây giờ mọi thứ phải tồn tại trước khi bạn có thể đẩy chúng vào những thứ khác. Tôi đã khám phá điều đó ở đây và đưa ra sơ đồ nhỏ dễ thương này:

Và bạn có thể xây dựng tất cả những thứ đó mà không cần rời đi main().

Tôi sẽ khuyên bạn nên sử dụng các nhà xây dựng và nhà máy khi bạn muốn chia một đống mã xây dựng theo thủ tục thành các khối khái niệm có kích thước cắn đẹp. Nhưng không có gì trong kiến ​​trúc sạch hoặc bất kỳ kiến ​​trúc từ thông dụng nào khác đòi hỏi bạn phải làm. Vì vậy, nếu bạn muốn gắn bó với main(), tốt. Xin vui lòng, xin thương xót .

Có phải Kiến trúc sạch sẽ của Martin Martin là một quy tắc chung cho tất cả các kiến ​​trúc hay nó chỉ là một trong những lựa chọn?

Tôi coi Kiến trúc sạch là một từ thông dụng được sử dụng để hướng mọi người đến một blog và một cuốn sách. Blog và cuốn sách đó có những giải thích rất hay về Kiến trúc cũ rất giống nhau với những cái tên cũ hơn được sử dụng để hướng mọi người đến blog cũ và sách cũ hơn. Cụ thể là Hành cũng như Cổng và Bộ điều hợp. Không ai trong số đó là lựa chọn kiến ​​trúc duy nhất bạn có.

Tôi thích chú Bob vì ông là một diễn giả và tác giả tuyệt vời. Anh ấy khiến tôi nghĩ về những thứ tôi sẽ không có. Nhưng nếu bạn để điều đó biến bạn thành một người nhiệt thành tôn giáo, người khăng khăng đòi mọi thứ phải được thực hiện theo cách của mình, bạn sẽ nhanh chóng thấy rằng việc cập nhật tài liệu là gần nhất tôi sẽ cho phép bạn nhận được mã của tôi.

Các kiến ​​trúc từ thông dụng rất hữu ích khi bạn có mã tồn tại lâu cần tồn tại trong khi thế giới thay đổi xung quanh nó. Đó là khi nó tỏa sáng. Nếu thế giới ổn định so với mã, thì bạn đang làm cho mọi thứ trở nên lạ mắt mà không có lý do chính đáng.

Không có vấn đề gì tuyệt vời như thế nào có một bối cảnh bạn có thể đặt nó vào đó sẽ làm cho nó vô lý. Xin lỗi, đây cũng không phải là viên đạn bạc.

Nhưng trong video tôi cảm thấy anh ấy gợi ý rằng kiến ​​trúc sạch sẽ có ranh giới rõ ràng giữa logic kinh doanh và khung. Các khung (web, android, v.v.) phải là các plugin cắm vào logic nghiệp vụ. Anh ấy thậm chí còn tinh tế chế giễu đường ray trong video.

Bạn đúng. Anh ấy làm. Chú Bob cảm thấy rằng các khung có thể được đối xử như các thư viện. Và họ có thể. Nhưng ngay cả quyết định đó cũng khiến bạn phải trả giá.

Những gì ông Martin đang cố gắng bảo tồn là một không gian nơi ngôn ngữ mục đích chung của bạn vẫn còn chung chung. Bạn từ bỏ điều đó khi bạn trải một khuôn khổ ở khắp mọi nơi. Khi bạn làm điều đó, bạn đang đi xuống con đường biến ngôn ngữ của bạn thành một thứ gọi là ngôn ngữ cụ thể của miền. HTML là một ngôn ngữ cụ thể miền. Nó hoạt động rất tốt nhưng có những công việc khác không thể làm được.

Miễn là nhu cầu của bạn được dự đoán bởi khuôn khổ, mọi thứ sẽ diễn ra rất suôn sẻ. Thật tốt khi có nhu cầu của bạn dự đoán. Nó đặt bạn trong một hộp giữ mọi thứ đơn giản. Chỉ cần hiểu những gì bạn đang từ bỏ để có được điều này. Nếu bạn truyền bá Spring ở mọi nơi, bạn không thể quảng cáo nó như một công việc Java nữa. Đó là một công việc Java / Spring. Tôi có thể nói điều tương tự về Ruby và Rails nhưng Rails đã ăn bữa trưa của Ruby từ lâu.

Để trích dẫn video:

"Bạn không muốn thực hiện hợp nhất thư trong SQL."

theo dõi bởi:

"Tôi thực sự đã thấy một thủ tục lưu trữ SQL là toàn bộ kết hợp thư"

Kiến trúc, giống như kết hợp thư, chỉ là một lựa chọn trong số nhiều.

Những gì không phải là tùy chọn là những vấn đề mà kiến ​​trúc đang cố gắng giải quyết.

Nếu bạn hiểu vấn đề hợp nhất thư SQL gây ra so với các giải pháp khác, thì lựa chọn kiến ​​trúc của bạn sẽ được thông báo và ngay cả khi bạn buộc phải chọn giải pháp 'xấu', bạn sẽ nhận thức được và giảm thiểu những thiếu sót lớn hơn.

Nếu bạn theo một phong cách kiến ​​trúc chỉ vì nó được nghĩ đến, thì bạn có khả năng mắc lỗi và gặp phải những vấn đề tương tự.

"Kiến trúc sạch" chắc chắn là "chỉ" một trong các tùy chọn. Tôi cho rằng nó là một trong những lựa chọn tồi cho hầu hết các dự án, đặc biệt là cho các dự án hướng đối tượng.

Dưới đây là phân tích từng câu trong bài viết của Bác Bob về Kiến trúc sạch với các lý do cho tuyên bố trên:

Kiến trúc sạch từ góc nhìn hướng đối tượng

Kiến trúc sạch là một tập hợp các nguyên tắc và mô hình để giải quyết một số triệu chứng phổ biến mà các tổ chức phát triển phần mềm thường gặp phải trong suốt thời gian xây dựng các ứng dụng phức tạp. Ông Martin đã đi rất lâu trong cuốn sách để xác định các triệu chứng và nguyên nhân gốc rễ dựa trên kinh nghiệm sâu rộng của ông trong lĩnh vực này và để làm rõ vai trò của kiến ​​trúc trong việc giảm thiểu những lo ngại này.

Tuy nhiên, đó không phải là Quy tắc của ngón tay cái, cũng không phải là thuốc chữa bách bệnh cho mọi người bệnh. Nếu bạn đọc cuốn sách, bạn sẽ hiểu rõ hơn về việc nếu / khi / làm thế nào để áp dụng các nguyên tắc và mô hình mà anh ấy ủng hộ (và sự đánh đổi liên quan). Nếu bạn chưa đọc cuốn sách này, bạn có thể đưa ra các giả định, ứng dụng, phán đoán và tuyên bố không chính xác dựa trên thông tin không đầy đủ.