Theo tôi, đó hoàn toàn không phải là ý nghĩa của nó. Và đó là vi phạm DRY.
Ý tưởng là đối tượng thực thể / miền ở giữa được mô hình hóa để đại diện cho miền tốt nhất và thuận tiện nhất có thể. Nó nằm ở trung tâm của mọi thứ và mọi thứ có thể phụ thuộc vào nó vì bản thân tên miền không thay đổi hầu hết thời gian.
Nếu cơ sở dữ liệu của bạn ở bên ngoài có thể lưu trữ các đối tượng đó trực tiếp, thì ánh xạ chúng sang định dạng khác nhằm mục đích tách các lớp không chỉ là vô nghĩa mà còn tạo ra các bản sao của mô hình và đó không phải là ý định.
Để bắt đầu, kiến trúc sạch đã được thực hiện với một môi trường / kịch bản điển hình khác nhau trong tâm trí. Các ứng dụng máy chủ doanh nghiệp với các lớp ngoài cùng cần các loại đối tượng đặc biệt của riêng chúng. Ví dụ cơ sở dữ liệu sản xuất SQLRowcác đối tượng và cần SQLTransactionstrả lại để cập nhật các mục. Nếu bạn sử dụng những người ở trung tâm, bạn đã vi phạm hướng phụ thuộc vì cốt lõi của bạn sẽ phụ thuộc vào cơ sở dữ liệu.
Với các ORM nhẹ tải và lưu trữ các đối tượng thực thể không phải là trường hợp. Họ thực hiện ánh xạ giữa nội bộ của họ SQLRowvà tên miền của bạn. Ngay cả khi bạn cần đặt một @Entitiychú thích của ORM vào đối tượng miền của mình, tôi vẫn cho rằng điều này không thiết lập "đề cập" của lớp bên ngoài. Bởi vì các chú thích chỉ là siêu dữ liệu, không có mã nào không đặc biệt tìm kiếm chúng sẽ thấy chúng. Và quan trọng hơn, không có gì cần thay đổi nếu bạn xóa chúng hoặc thay thế chúng bằng chú thích của cơ sở dữ liệu khác.
Ngược lại, nếu bạn thay đổi tên miền của mình và bạn đã tạo ra tất cả những người lập bản đồ đó, bạn phải thay đổi rất nhiều.
Sửa đổi: Trên đây là một chút đơn giản hóa và thậm chí có thể sai. Bởi vì có một phần trong kiến trúc sạch sẽ muốn bạn tạo một đại diện cho mỗi lớp. Nhưng điều đó phải được nhìn thấy trong bối cảnh của ứng dụng.
Cụ thể như sau đây https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arch architecture.html
Điều quan trọng là các cấu trúc dữ liệu đơn giản, đơn độc được truyền qua các ranh giới. Chúng tôi không muốn gian lận và vượt qua các hàng Thực thể hoặc Cơ sở dữ liệu. Chúng tôi không muốn các cấu trúc dữ liệu có bất kỳ loại phụ thuộc nào vi phạm Quy tắc phụ thuộc.
Việc chuyển các thực thể từ trung tâm sang các lớp bên ngoài không vi phạm quy tắc phụ thuộc, tuy nhiên chúng được đề cập. Nhưng điều này có một lý do trong bối cảnh của ứng dụng được hình dung. Vượt qua các thực thể xung quanh sẽ di chuyển logic ứng dụng ra bên ngoài. Các lớp bên ngoài sẽ cần phải biết cách diễn giải các đối tượng bên trong, chúng thực sự sẽ phải làm những gì các lớp bên trong như lớp "trường hợp sử dụng" phải làm.
Bên cạnh đó, nó cũng tách riêng các lớp để thay đổi lõi không nhất thiết yêu cầu thay đổi ở các lớp bên ngoài (xem bình luận của SteveCallender). Trong bối cảnh đó, thật dễ dàng để xem các đối tượng nên thể hiện cụ thể mục đích mà chúng được sử dụng như thế nào. Ngoài ra, các lớp nên nói chuyện với nhau về các đối tượng được tạo riêng cho mục đích giao tiếp này. Điều này thậm chí có thể có nghĩa là có 3 biểu diễn, 1 trong mỗi lớp, 1 để vận chuyển giữa các lớp.
Và có https://blog.8thlight.com/uncle-bob/2011/11/22/Clean-Arch architecture.html địa chỉ trên:
Những người khác đã lo lắng rằng kết quả ròng của lời khuyên của tôi sẽ là rất nhiều mã trùng lặp và rất nhiều bản sao dữ liệu từ cấu trúc dữ liệu này sang cấu trúc dữ liệu khác trên các lớp của hệ thống. Chắc chắn tôi cũng không muốn điều này; và không có gì tôi đã đề xuất chắc chắn sẽ dẫn đến sự lặp lại các cấu trúc dữ liệu và sự không phù hợp của sao chép trường.
IMO đó ngụ ý rằng việc sao chép các đối tượng đơn giản 1: 1 là một mùi trong kiến trúc bởi vì bạn không thực sự sử dụng các lớp và / hoặc trừu tượng thích hợp.
Sau đó, anh giải thích cách anh tưởng tượng tất cả sự "sao chép"
Bạn tách giao diện người dùng khỏi các quy tắc kinh doanh bằng cách chuyển các cấu trúc dữ liệu đơn giản giữa hai quy tắc. Bạn không để bộ điều khiển của bạn biết bất cứ điều gì về các quy tắc kinh doanh. Thay vào đó, các bộ điều khiển giải nén đối tượng HttpRequest vào cấu trúc dữ liệu vanilla đơn giản và sau đó chuyển cấu trúc dữ liệu đó đến một đối tượng tương tác thực hiện trường hợp sử dụng bằng cách gọi các đối tượng kinh doanh. Sau đó, bộ tương tác tập hợp dữ liệu phản hồi vào một cấu trúc dữ liệu vanilla khác và chuyển nó trở lại UI. Các quan điểm không biết về các đối tượng kinh doanh. Họ chỉ nhìn vào cấu trúc dữ liệu đó và trình bày phản hồi.
Trong ứng dụng này, có một sự khác biệt lớn giữa các đại diện. Dữ liệu chảy không chỉ là các thực thể. Và điều này đảm bảo và yêu cầu các lớp khác nhau.
Tuy nhiên, áp dụng cho một ứng dụng Android đơn giản như trình xem ảnh trong đó Photothực thể có khoảng 0 quy tắc kinh doanh và "trường hợp sử dụng" liên quan đến chúng gần như không tồn tại và thực sự quan tâm nhiều hơn đến bộ nhớ đệm & tải xuống (quá trình đó nên IMO được trình bày rõ ràng hơn), điểm để tạo các biểu diễn riêng biệt của một bức ảnh bắt đầu biến mất. Tôi thậm chí có cảm giác rằng chính bức ảnh là đối tượng truyền dữ liệu trong khi lớp lõi logic kinh doanh thực sự bị thiếu.
Có một sự khác biệt giữa "tách giao diện người dùng khỏi quy tắc kinh doanh bằng cách chuyển các cấu trúc dữ liệu đơn giản giữa hai" và "khi bạn muốn hiển thị ảnh đổi tên nó 3 lần trên đường đi" .
Bên cạnh đó, điểm mà tôi thấy các ứng dụng demo đó thất bại trong việc thể hiện kiến trúc sạch là chúng chú trọng rất lớn vào việc tách các lớp nhằm mục đích tách các lớp nhưng che giấu hiệu quả những gì ứng dụng làm. Điều đó trái ngược với những gì được nói trong https://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Arch architecture.html - cụ thể là
kiến trúc của một ứng dụng phần mềm hét lên về các trường hợp sử dụng của ứng dụng
Tôi không thấy sự nhấn mạnh vào việc tách các lớp trong kiến trúc sạch. Đó là về hướng phụ thuộc và tập trung vào việc đại diện cho cốt lõi của ứng dụng - các thực thể và trường hợp sử dụng - trong java đơn giản lý tưởng mà không phụ thuộc vào bên ngoài. Đó không phải là quá nhiều về sự phụ thuộc vào cốt lõi đó.
Vì vậy, nếu ứng dụng của bạn thực sự có lõi đại diện cho các quy tắc kinh doanh và trường hợp sử dụng và / hoặc những người khác nhau làm việc trên các lớp khác nhau, vui lòng tách chúng theo cách đã định. Mặt khác, nếu bạn chỉ viết một ứng dụng đơn giản thì đừng quá lạm dụng nó. 2 lớp với giới hạn trôi chảy có thể là quá đủ. Và các lớp có thể được thêm vào sau này là tốt.
BankAccountnhưng với các quy tắc cụ thể của ứng dụng, bạn có thể làm gì với tài khoản đó.