Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4
SỬ DỤNG KIỂU MÔ HÌNH MIỀN.
Udi Dahan
Bài này thảo luận các vấn đề sau:
- Kiểu mô hình miền.
- Những viễn cảnh trong việc sử dụng kiểu mô hình miền.
- Các sự kiện miền.
- Giữ việc kinh doanh trong giới hạn
Mục này sử dụng các công nghệ sau: kiểu mô hình miền.
Trong bài này, chúng ta sẽ nghiên cứu các lý do để sử dụng (hoặc không sử dụng) kiểu mô hình miền, các lợi ích mà nó mang lại, cũng như cung cấp một số lời khuyên thiết thực trong việc dựa theo các giải pháp tổng thể đơn giản như có thể.
Nội dung trong bài này:
- Kiểu mô hình miền là gì?
- Những lý do không sử dụng công nghệ mô hình miền.
- Các viễn cảnh khi không dụng mô hình miền.
- Các viễn cảnh khi dụng mô hình miền.
- Các tương tác phức tạp hơn.
- Áp dụng các quy tắc kinh doanh.
- Các sự kiện miền và các lời gọi của chúng.
- Nghiên cứu chi tiết các sự kiện miền.
- Khả năng kiểm tra.
- Các lệnh và câu truy vấn.
- Giữ việc kinh doanh trong giới hạn.
- Sự kết hợp.
- Tìm một giải pháp tổng thể.
- Trích dẫn.
Nếu bạn có gặp tôi vài năm trước đây và hỏi tôi đã từng sử dụng các kiểu mô hình miền chưa và tôi sẽ đáp lại bằng câu trả lời là tuyệt đối “có”. Tôi chắc chắn về sự hiểu biết của tôi về kiểu này. Tôi đã có hỗ trợ để làm cho nó được thực thi.
Nhưng tôi đã hoàn toàn sai.
Sự hiểu biết của tôi đã mở rộng hơn trong những năm qua và tôi đã được đánh giá cao về cách làm ứng dụng có thể có lợi từ việc xếp chính nó với cùng những nguyên tắc điều khiển cùng miền.
Trong bài này, chúng ta sẽ nghiên cứu tại sao chúng ta muốn sử dụng kiểu mô hình miền (cũng như tại sao không), các lợi ích mà nó mang lại, làm thế nào để nó tương tác với các phần khác của một ứng dụng và các tính năng chúng ta muốn được cung cấp bởi các công nghệ có hỗ trợ và thảo luận về một số lời khuyên thiết thực trong việc dựa theo các giải pháp tổng thể đơn giản như có thể.
Kiểu mô hình miền là gì?
Tác giả của kiểu mô hình miền này, Martin Fowler, đã đưa định nghĩa (Fowler, 2003): “Một mô hình đối tượng của miền kết hợp cả cách thức hoạt động và dữ liệu”.
Để bạn hiểu đúng, định nghĩa này có thể được giải thích để phù hợp với hầu hết các đoạn mã – một lý do hay là tại sao tôi nghĩ rằng tôi đã sử dụng mô hình này trong khi trên thực tế tôi đã không làm theo đúng với mục đích ban đầu của nó.
Chúng ta hãy xem xét kĩ hơn.
Những lý do không dùng mô hình miền
Trong phần văn bản theo như mô tả ban đầu, trước tiên tôi đã lướt qua đoạn trích không mang nhiều ý nghĩa lắm nhưng nó chỉ ra nhiều quyết định quan trọng phụ thuộc vào việc hiểu nó.
Vì hành vi kinh doanh phụ thuộc vào nhiều thay đổi, điều đó thật quan trọng để sửa, xây dựng và kiểm tra tầng này một cách dễ dàng. Kết quả là bạn sẽ muốn tối thiểu các chuỗi hành động từ Mô hình miền đến các tầng khác trong hệ thống.
Vì vậy, một trong những lý do không sử dụng mẫu mô hình miền là việc kinh doanh mà phần mềm của bạn đang tự động hóa không có thay đổi nhiều. Điều đó không nói lên rằng nó không có thay đổi nào cả - thay vì các quy định nằm bên dưới ra lệnh việc kinh doanh không phải là rất cơ động. Trong khi các yếu tố công nghệ và môi trường khác có thể thay đổi, đó không phải là ngữ cảnh của mô hình này.
Một số ví dụ về mô hình này bao gồm hỗ trợ đa cơ sở dữ liệu (như là SQL Server và Oracle) hoặc các công nghệ đa giao diện (Windows, Web, Mibile và …). Nếu hành vi kinh doanh không thay đổi, các ví dụ này không minh chứng cách sử dụng kiểu mô hình miền được. Điều đó không nói lên rằng ta không nhận được nhiều giá trị từ việc sử dụng những công nghệ hỗ trợ mô hình này nhưng chúng ta cần phải trung thực về các quy định mà chúng ta phá vỡ và tại sao.
Những lý do sử dụng kiểu mô hình miền
Trong những trường hợp mà hành vi kinh doanh tùy thuộc vào nhiều thay đổi, có một mô hình miền sẽ giảm tổng chi phí của các thay đổi đó. Có tất cả các hành vi kinh doanh có thể thay đổi được gói gọn trong một phần riêng lẻ của phần mềm của chúng ta để giảm thời lượng chúng ta cần để thực hiện một thay đổi vì tất cả sẽ được thực hiện ở một nơi. Bằng cách cô lập đoạn mã đó càng nhiều càng tốt, chúng ta đã làm giảm các thay đổi có khả năng xảy ra ở những nơi khác là nguyên nhân phá vỡ, do đó làm giảm thời gian cần để ổn định hệ thống.
Các viễn cảnh khi không dùng kiểu mô hình miền
Điều này dẫn chúng ta đến sai lầm số 1 và phổ biến nhất trong việc sử dụng các mô hình miền. Bản thân tôi đã phạm phải sai lầm trong việc tạo ra giả thiết sai trong vài năm và bây giờ tôi đã nhìn thấy nơi mà nó dẫn tôi lạc lối.
Sai lầm: Bất kì mô hình đối tượng ổn định nào đều là mô hình miền
Trước hết, một mô hình đối tượng ổn định nào vốn dĩ đều không gói gọn các hành vi kinh doanh có khả năng thay đổi. Thứ hai, một đối tượng ổn định có thể bao gồm các chức năng không phải là có khả năng thay đổi.
Bản chất của sai lầm này cũng tương tự như nói rằng cái tua vít là cái búa. Trong khi bạn (có thể thử) búa trong móng tay bằng một cái tua vít, bạn sẽ không đạt được hiệu quả khi làm vậy.
Mang sai lầm này trở lại những tình huống cụ thể mà chúng ta đều biết và yêu thích, hãy xem xét các yêu cầu hiện nay rằng một địa chỉ email của người dùng phải là duy nhất.
Một lúc, tôi đã nghĩ rằng điểm mấu chốt để có một mô hình miền là các yêu cầu như thế này sẽ được thực thi ở đó. Tuy nhiên, khi chúng tôi xem xét các hướng dẫn rằng các mô hình miền nói về việc lưu giữ các hoạt động kinh doanh phụ thuộc vào thay đổi, chúng tôi có thể thấy rằng yêu cầu này không phù hợp với khuôn mẫu. Nó giống như rằng yêu cầu này sẽ chẳng bao giờ thay đổi.
Do đó, việc chọn thực thi như một yêu cầu trong phần này của hệ thống đó là gói gọn những phần hay thay đổi của việc kinh doanh để cho nó ít đi, có thể là khó thực hiện và cũng có thể là thực hiện không tốt. Đưa tất cả các địa chỉ email vào bộ nhớ có thể khiến bạn bị khóa quyền thực thi. Thậm chí đang có một mô hình miền gọi một dịch vụ nào đó gọi cơ sở dữ liệu, cho thấy rằng để các địa chỉ email ở đó là không cần thiết. Một ràng buộc duy nhất trong cơ sở dữ liệu sẽ đủ để đáp ứng nhu cầu.
Tư duy thực dụng này được dùng nhiều trong bản chất của kiểu mô hình miền và thiết kế miền điều khiển và là những gì sẽ giữ những điều đơn giản ngay cả khi chúng ta giải quyết các yêu cầu khác liên quan hơn sự độc đáo của một email đơn giản.
Những viễn cảnh khi dùng mô hình miền
Việc kinh doanh quy định rằng chỉ khi các hành động nhất định được cho phép là những ứng viên tốt để được thực hiện trong một mô hình miền.
Ví dụ, trong một hệ thống thương mại điện tử một quy định chỉ ra rằng một khách hàng có thể không có nhiều hơn 1000$ trong các hóa đơn chưa thanh toán sẽ thuộc trong một mô hình miền. Lưu ý rằng quy định này bao gồm nhiều thực thể và cần phải được đánh giá trong nhiều trường hợp sử dụng.
Dĩ nhiên, trong một mô hình miền được đưa ra chúng tôi mong muốn thấy nhiều loại trong các loại này của những quy định, bao gồm các trường hợp một số quy định ghi đè lên những quy định khác. Trong ví dụ trên, nếu người dùng thực hiện một thay đổi một yêu cầu là người quản lý tài khoản của khách hàng đó, sau đó quy định trước đó không còn được áp dụng nữa.
Không cần thiết phải dành thời gian nghiên cứu quy định nào cần áp dụng trong các trường hợp sử dụng và nhanh chóng đưa ra các danh sách các thực thể và mối quan hệ giữa chúng – tránh “để thiết kế lớn lên trước” cơ sở thực tế đó chống lại. Tuy nhiên, các quy tắc kinh doanh và các trường hợp sử dụng là rất nhiều lý do chúng ta áp dụng mẫu mô hình miền tại nơi đầu tiên.
Khi giải quyết các loại vấn đề trong quá khứ, tôi sẽ không nghĩ 2 lần và đã có thể thiết kế một lớp Customer với một bộ sưu tập các đối tượng Order. Nhưng các quy tắc của chúng tôi cho đến giờ cho thấy chỉ một thuộc tính đơn lẻ trên Customer thay vì UnpaidOrdersAmount. Chúng ta có thể nghiên cứu vài quy tắc và không thực sự đi sâu vào thứ gì đó rõ ràng chỉ tới một sự kết hợp các Order. Trong trường hợp đó, câu châm ngôn “bạn sẽ không cần nó” (YAGNI) sẽ chặn không cho chúng ta tạo ra sự kết hợp đó.
Khi nhìn vào tính liên tục của đồ thị của các đối tượng, chúng ta có thể thấy rằng nó thích hợp để thêm các đối tượng hỗ trợ và các bộ sưu tập bên dưới. Chúng ta cần phân biệt rõ ràng giữa các chi tiết thực thi và các hành vi kinh doanh cốt lõi là trách nhiệm của mô hình miền.
Các tương tác phức tạp hơn
Xem xét yêu cầu khi một khách hàng đã mua hơn 10.000$ tại công ty của chúng ta, họ trở thành một khách hàng “thân thiết”. Khi một khách hàng trở thành khách hàng thân thiết, hệ thống sẽ chuyển đến họ một email thông báo về những lợi ích của chương trình khách hàng thân thiết của chúng ta.
Điều gì làm cho kịch bản này khác so với yêu cầu địa chỉ email duy nhất đã mô tả trước đó là sự tương tác này không nhất thiết liên quan đến mô hình miền. Một tùy chọn là để thực hiện sự logic trong đoạn mã này là gọi mô hình miền như sau:
Một trở ngại mà đoạn mã ví dụ né tránh là kiểm tra số tiền chỉ định khi một khách hàng trở thành khách hàng thân thiết. Sự logic đó được giao phó cho mô hình miền một cách thích hợp.
Thật không may, chúng ta có thể thấy rằng đoạn mã ví dụ có khả năng nảy sinh thêm các quy tắc được thêm vào hệ thống hơn mà cần phải được đánh giá khi các đơn đặt hàng được gửi đi. Thậm chí chúng ta di chuyển đoạn mã này vào mô hình miền, chúng ta vẫn muốn được để cùng các vấn đề sau.
Áp dụng các quy tắc kinh doanh:
Có thể có nhiều trường hợp sử dụng khác đưa đến kết quả là khác hàng trở thành khách hàng thân thiết. Chúng ta sẽ không muốn có một sự trùng lặp logic đó ở nhiều nơi (cho dù nó có ở trong mô hình miền hay không), đặc biệt là vì sự phân tích lại một phương thức đã được trích ra sẽ vẫn đòi hỏi việc lưu giữ tình trạng thân thiết ban đầu của khách hàng.
Chúng ta thậm chí cần phải đi xa như vậy để bao gồm một vài loại phương thức lập trình phân cách / theo hướng đối tượng (AOP) để tránh sự trùng lặp.
Dường như chúng tôi nên suy nghĩ lại cách tiếp cận trước khi áp dụng phương pháp “dao cạo của Occam”. Nhìn lại những yêu cầu của chúng ta lần nữa có thể cho chúng ta một số định hướng.
Khi một khách hàng đã trở thành [một cái gì đó] mà hệ thống nên [làm điều gì đó].
Chúng tôi dường như quên mất một cách hay để thể hiện cho mẫu yêu cầu này, mặc dù điều này nghe có vẻ giống như thứ gì đó mà một mô hình sự kiện cơ sở sử dụng nó rất tốt. Bằng cách đó, nếu chúng ta yêu cầu làm nhiều hơn nữa trong phần “nên làm điểu gì đó”, chúng ta có thể dễ dàng thực hiện điều đó như là một xử lý sự kiện bổ sung.
Các sự kiện miền và các lời gọi hàm của chúng
Sự kiện miền là cách mà chúng tôi miêu tả một cách rõ ràng cho phần đầu tiên của yêu cầu được mô tả:
Khi [một thứ gì đó] trở thành [một thứ gì đó]…
Trong khi chúng ta có thể thực hiện các sự kiện này trên các thực thể chính nó, nó có thể mang lại thuận lợi để chúng có thể được truy cập ớ cấp độ toàn miền. Hãy so sánh làm cách nào mà tầng dịch cụ có thể xử lý cả 2 trường hợp:
Trong khi điều hay là nó không kiểm tra tình trạng trước và sau lời gọi, chúng tôi đã chuyển phức tạp đó bằng việc đăng kí và gỡ bỏ các đăng kí từ sự kiện miền. Vì thế, đoạn mã gọi mô hình miền trong bất kì trường hợp sử dụng nào chắc hẳn sẽ không biết nếu một khách hàng có thể trở thành thân thiết ở đó. Nhưng xem xét rằng khi gửi đơn đặt hàng, chúng ta có thể mang đến kho của một trong những sản phẩm đặt hàng dưới ngưỡng bổ sung của nó – chúng ta cũng không muốn sử dụng sự kiện đó trong đoạn mã.
Sẽ tốt hơn nếu chúng ta có từng sự kiện được xử lý bởi một lớp dành riêng mà không xử lý bất kì trường hợp sử dụng cụ thể nào nhưng có thể được kích hoạt trong tất cả các trường hợp sử dụng. Đây là một lớp như là:
Chúng ta sẽ thảo luận về loại cơ sở hạ tầng sẽ làm cho lớp này được gọi khi cần thiết, nhưng hãy xem những gì còn lại của đoạn mã gửi đơn hàng gốc:
Đó có thể là một mô hình đơn giản mà chúng ta hi vọng – đoạn mã của chúng ta không cần biết bất kì điều gì về các sự kiện đó.
Nghiên cứu chi tiết các sự kiện miền
Trong lớp CustomerBecamePreferredHandler chúng ta xem tham chiếu đến một loại được gọi là CustomerBecamePreferred – một thể hiện rõ ràng trong đoạn mã việc xuất hiện được đề cập trong yêu cầu. Lớp này có thể đơn giản như sau:
Bước tiếp theo là phải có khả năng cho bất kì lớp nào trong phạm vi mô hình miền của chúng ta như một sự kiện, là một cách thể hiện dễ dàng với các lớp tĩnh sau làm cho việc sử dụng một thùng chứa như Unity, Castle hoặc Spring.NET:
Bây giờ bất kì lớp nào trong mô hình miền có thể làm tăng một sự kiện miền, với các lớp thực thể thường làm tăng các sự kiện như là:
Khả năng kiểm tra
Trong khi lớp DomainEvents được thể hiện là chức năng, nó có thể làm đơn vị để kiểm tra một mô hình miền hơi cồng kềnh vì chúng ta cần phải tận dụng các vật chứa các sự kiện miền được gia tăng đó. Một cài bổ sung cho lớp DomainEvents có thể tránh vấn đề, như được trình bày trong Minh họa 1:
Minh họa 1: Các bổ sung cho lớp DomainEvents.
Bây giờ một đơn vị kiểm tra có thể hoàn toàn khép kín mà không cầ vật chứa nào, như Minh họa 2 trình bày:
Minh họa 2: Đơn vị kiểm tra không vật chứa.
Các dòng lệnh và câu truy vấn
Các trường hợp sử dụng chúng tôi đang ví dụ đã được giải quyết bằng cách thay đổi dữ liệu và các quy tắc liên quan. Tuy vậy, trong nhiều hệ thống, những người dùng cũng cần có thể xem dữ liệu này, cũng như thực hiện các loại tìm kiếm, sắp xếp và lọc.
Ban đầu tôi đã nghĩ rằng các lớp thực thể giống nhau được đặt trong mô hình miền nên được sử dụng để thể hiện dữ liệu cho người dùng. Trong những năm qua, tôi đã quen với việc hiểu rằng suy nghĩ ban đầu của tôi thường hóa ra sai. Mô hình miền nói về việc đóng gói dữ liệu bằng các hành vi kinh doanh.
Việc hiển thị thông tin người dùng không liên quan đến hành vi kinh doanh và nói vể việc “mớ của” dữ liệu. Thậm chí khi chúng ta có những yêu cầu bảo mật hiện thời xung quang việc người dùng có thể thông tin gì, mà thường được thể hiện như một bộ lọc bắt buộc của dữ liệu.
Trong khi chúng tôi “thành công” trong quá khứ trong việc tạo ra một mô hình đối tượng đơn lẻ duy nhất xử lý cả các câu lệnh và câu truy vấn, nó thường rất khó để thu hẹp lại vì mỗi phần của hệ thống kéo mô hình theo một hướng khác.
Điều đó chỉ ra rằng các nhà phát triển đặt thêm các yêu cầu tích cực hơn việc kinh doanh thực sự cần. Quyết định sử dụng các thực thể mô hình miền để thể hiện thông tin cho người dùng chỉ như một ví dụ.
Như bạn thấy đấy, trong một hệ thống nhiều người dùng, các thay đổi được thực hiện bởi một người dùng không nhất thiết ngay lập tức hiển thị cho tất cả những người dùng khác. Chúng ta ngầm hiểu điều này khi chúng tôi giới thiệu bộ nhớ đệm để cải thiện hiệu suất – nhưng vẫn còn những câu hỏi chuyên sâu hơn: khi bạn không cần dữ liệu cập nhật hiện thời, tài sao nghiên cứu mô hình miền cần làm việc trên dữ liệu đó? Nếu bạn không cần hành vi được tạo ra trong các lớp mô hình miền, tại sao phải duyệt qua chúng để được dữ liệu của họ?
Đối với những người đủ tuổi để nhớ, những bài tập tốt nhất xung quanh việc xử dụng COM+ đã hướng dẫn chúng ta tạo ra các thành phần riêng biệt cho logic chỉ đọc và đọc-ghi. Chúng ta ở đây, một thập kỉ sau đó, với những công nghệ mới như Entity Framework, nhưng những nguyên tắc kia vẫn được sử áp dụng.
Lấy dữ liệu từ cơ sở dữ liệu và hiển thị nó cho người dùng là một vấn đề bình thường để giải quyết ngày nay. Việc này đơn giản như một bộ đọc ADO.NET hoặc tập dữ liệu.
Minh họa 3 cho thấy kiến trúc mới của chúng ta trông như thế nào.
Minh họa 3: Mô hình lấy dữ liệu từ một cơ sở dữ liệu.
Một điều là điều đó rất khác trong mô hình này từ những cách tiếp cận phổ biến được dựa trên sự ràng buộc dữ liệu 2 chiều, là cấu trúc được sử dụng để hiển thị dữ liệu không được dùng để thay đổi. Điều này làm cho những việc như theo dõi sự thay đổi không hoàn toàn cần thiết.
Trong kiến trúc này, dữ liệu chuyển lên phía bên phải từ cơ sở dữ liệu đến người dùng bằng hình thức của các câu truy vấn và xuống bên trài từ người dùng rồi quay trở lại cơ sở dữ liệu bằng hình thức của các dòng lệnh. Cách chọn để đi đến cơ sở dữ liệu hoàn toàn tách biệt được dùng cho những câu truy vấn kia là một lựa chọn hấp dẫn về hiệu suất và khả năng mở rộng, vì việc đọc không ảnh hưởng việc ghi trong cơ sở dữ liệu (gồm những trang của dữ liệu được lưu trữ trong bộ nhơ trong cơ sở dữ liệu), nhưng một cơ chế đồng bộ rõ ràn giữa 2 dữ liệu là bắt buộc. Các tùy chọn cho việc này gồm ADO.NET Sync Services, SQL Server Intergration Services (SSIS) và xuất bản/đăng kí thông điệp. Việc chọn một trong những vượt ra ngoài phạm vi của bài này.
Giữ việc kinh donh trong giới hạn
Một trong những thách thức mà các nhà phát triển phải đối mặt khi thiết kế một mô hình miền là lám cách nào để đảm bảo rằng logic kinh doanh không thất thoát ngoài mô hình miền.Không có một giải pháp phụ nào cho vấn đề này, nhưng một phong cách làm việc quản lý để tìm ra sự cân bằng tinh tế giữa sự đồng nhất, tính đúng đắn và việc đóng gói miền thậm chí có thể được thử nghiệm bằng các công cụ phân tích tĩnh như FxCop.
Dưới đây là ví dụ về loại đoạn mã mà chúng ta không muốn thấy sự tương tác với một mô hình miền:
Mặc dù đoạn mã này hơi hướng đối tượng, chúng ta có thể thấy rằng một số lượng nhất định logic kinh doanh đang được thể hiện ở đây hơn là trong mô hình miền. Một cách tiếp cận thích hợp hơn:
Trong trường hợp đơn hàng mới vượt quá giới hạn của các đơn hàng chưa thanh toán, nó sẽ được thể hiện bằng một sự kiện miền, được quản lý bởi một lớp riêng biệt như trước đây đã chứng minh. Phương thức mua hàng sẽ không gây ra bất kì sự thay đổi dữ liệu nào trong trường hợp đó, kết quả trong một giao dịch thành công về mặt kĩ thuật mà không có bất kì tác động kinh doanh nào.
Khi kiểm tra sự khác nhau giữa 2 đoạn code ví dụ, chúng ta có thể thấy rằng việc gọi đơn hàm duy nhất trong mô hình miền là cần thiết nghĩa là tất cả logic kinh doanh phải được đóng gói ở đó. Tập trung nhiều vào các API của mô hình miền thường được cải tiến thêm khả năng kiểm tra.
Trong khi đây là bước tốt trong định hướng đúng đắn, nó mở ra một số câu hỏi về sự thống nhất.
Sự thống nhất
Bạn thấy đấy, tại thời điểm nơi chúng tôi có được khách hàng và thời điểm chúng tôi yêu cầu việc mua hàng, giao dịch khác có thể đi vào và thay đổi khách hàng bằng cách là lượng đơn đặt hàng chưa được thanh toán được cập nhật. Điều này có thể là nguyên nhân gây ra việc giao dịch của chúng tôi để thực hiện việc mua hàng (dựa vào dữ liệu được lấy ra trước đó), mặc dù nó không tuân theo các trạng thái được cập nhật.
Cách đơn giản nhất để giải quyết vấn đề này là khóa hồ sơ của khách hàng khi chúng tôi đọc nó lần đầu tiên – được thực hiện bằng cách chỉ ra một mức cô lập giao dịch ít nhất là một lần đọc lại (hoặc nối tiếp – là mặc định) như sau:
Mặc dù việc này tốn nhiều chi phí để khóa hơn là đọc tầng cô lập một vài môi trường thực hiện tốt đã giải quyết, sự thể hiện có thể được duy trì tại các tầng tương tự khi các thực thể đã tham gia vào một trường hợp sử dụng được đưa ra được tải và được kết nối bằng các cột được lập chỉ mục. Điều này thường được bù đắp bằng mô hình mã ứng dụng hơn bởi vì không đoạn mã nào được yêu cầu để xác thực hoặc giải quyết các vấn đề đồng thời. Khi sử dụng một cơ sở dữ liệu riêng biệt cho các phần truy vấn của hệ thống và tất cả các lần đọc được tải từ cơ sở dữ liệu OLTP phục vụ mô hình miền, sự thể hiện và khả năng mở rộng có thể hầu như giống hệt nhau cho các cách giải quyết dựa trên cách đọc.
Tìm một giải pháp tổng thể
Thực sự kiểu mô hình miền là một công cụ mạnh mẽ trong tay của một nghệ nhân có tay nghề cao. Giống như nhiều nhà phát triển khác, lần đầu tiên tôi nhặt công cụ này, tôi dùng nó rất nhiều và thậm chí có thể đã lạm dụng nó để được các kết quả như ý. Khi thiết kế một mô hình miền, dành nhiều thời gian hơn để nhìn vào các chi tiết cụ thể được tìm thấy trong các trường hợp sử dụng khác nhau hơn là nhảy trực tiếp vào các mối quan hệ mô hình thực thể cho các mục đích hiển thị dữ liệu người dùng. Việc đó được phục vụ tốt hơn bằng cách truy vấn cơ sở dữ liệu đơn giản và dễ hiểu, bằng một tầng mỏng mặt chính ở trên nó đối với một số cơ sở dữ liệu được cung cấp độc lập.
Khi nhìn váo cách đoạn mã bên ngoài mô hình miền tương tác với nó, tìm “thứ giản nhất có thể làm việc được” – một phương thức đơn gọi một đối tượng đơn từ miền, thậm chí trong trường hợp khi bạn đang làm việc trên đa đối tượng. Các sự kiện miền có thể giúp tìm ra giải pháp của bạn để xử lý các tương tác phức tạp hơn và các tích hợp công nghệ mà không gây ra bất kì biến chứng nào.
Khi bắt đầu xuống đường dẫn này, tôi đã tốn một ít thời gian để chính lại suy nghĩ của mình, nhưng những ích lợi của từng kiểu được cảm nhận rất nhanh chóng. Khi tôi bắt đầu sử dụng tất cả các kiểu với nhau, tôi nhận thấy rằng chúng đã cung cấp một giải pháp toàn diện để ngay cả các lĩnh vực kinh doanh đòi hỏi nhất, trong khi vẫn giữ tất cả các đoạn mã trong từng phần của hệ thống nhỏ, tập trung và kiểm tra được – tất cả những gì một nhà phát triển mong muốn.
Trích dẫn
Fowler, M. Patterns of Enterprise Application Architecture, (Addison Wesley, 2003).
Udi Dahan được công nhận là một MVP, chuyên gia kiến trúc IASA, giáo sư Dobb’s SOA Guru, Udi Dahan là chuyên gia phần mềm, một cố vấn độc lập, người phát ngôn, tác giả và người huấn luyện cung cấp các dịch cụ cao cấp theo định hướng dịch vụ, có khả năng mở rộng và an toàn kiến trúc doanh nghiệp. Liên hệ Udi qua blog tại UdiDahan.com.
Nguồn: http://msdn.microsoft.com/en-us/magazine/ee236415.aspx.
-------------------------------------------------------------------------------------------------------------------------
Thông tin người dịch:
Họ và tên: Trần Nguyễn Đức Huy.
Email: zutafe@yahoo.com.
