Các bài viết liên quan:
Các mô hình tổ chức logic Domain
Trong việc tổ chức logic Domain, chúng tôi đã tách nó thành ba loại chính: Transaction script, Domain Model và Table Module.
Transaction Script
Cách tiếp cận đơn giản nhất để lớp Domain logic là Transaction script. Transaction script về cơ bản là một thủ tục lấy đầu vào từ lớp presentation, xử lý nó với các xác nhận và tính toán, lưu trữ dữ liệu trong cơ sở dữ liệu và gọi bất kỳ hoạt động nào từ các hệ thống khác. Sau đó, nó trả lời với nhiều dữ liệu hơn cho bản presentation, có thể thực hiện nhiều tính toán hơn để giúp tổ chức và định dạng câu trả lời.
Tổ chức cơ bản là duy nhất một thủ tục cho mỗi hành động mà người dùng có thể muốn thực hiện. Do đó, chúng ta có thể coi mẫu này là một kịch bản cho một hành động hoặc giao dịch kinh doanh. Nó không phải là một thủ tục nội tuyến duy nhất của mã. Các mảnh được tách thành các chương trình con và các chương trình con này có thể được chia sẻ giữa các Transaction script khác nhau. Tuy nhiên, động lực vẫn là quy trình cho mỗi hành động, vì vậy hệ thống bán lẻ có thể có Transaction script để thanh toán, để thêm thứ gì đó vào giỏ hàng, để hiển thị trạng thái giao hàng, v.v.
Transaction script cung cấp một số ưu điểm:
- Đây là một mô hình thủ tục đơn giản mà hầu hết các nhà phát triển đều hiểu.
- Nó hoạt động tốt với một lớp nguồn dữ liệu đơn giản sử dụng Cổng Dữ liệu Hàng
- hoặc Cổng Dữ liệu Bảng.
Rõ ràng là làm thế nào để thiết lập ranh giới Transaction: Bắt đầu bằng việc mở một giao dịch và kết thúc bằng việc đóng nó. Thật dễ dàng để các công cụ thực hiện điều này ở hậu trường.
Đáng buồn thay, cũng có rất nhiều nhược điểm, có xu hướng xuất hiện khi độ phức tạp của logic Domain tăng lên. Thường sẽ có mã trùng lặp vì một số giao dịch cần thực hiện những điều tương tự. Một số trường hợp này có thể được xử lý bằng cách gộp các chương trình con phổ biến ra ngoài, nhưng ngay cả khi quá nhiều sự trùng lặp cũng rất khó để loại bỏ và khó phát hiện hơn. Ứng dụng kết quả có thể trở thành một mạng lưới các quy trình khá rối mà không có cấu trúc rõ ràng.
Domain Model
Tất nhiên, logic phức tạp là nơi các đối tượng xuất hiện và cách để hướng đối tượng xử lý vấn đề này là với Domain Model. Với Domain, chúng tôi xây dựng Domain Model của chúng ta, ít nhất là trên ước tính đầu tiên, được tổ chức chủ yếu xung quanh các danh từ trong Domain. Do đó, một cho hệ thống thuê nhà sẽ có các lớp cho thuê, tài sản, v.v.
Logic để xử lý xác thực và tính toán sẽ được đặt vào Domain Model này, vì vậy đối tượng lô hàng có thể chứa logic để tính phí vận chuyển cho một lần giao hàng. Vẫn có thể có các quy trình tính toán hóa đơn, nhưng quy trình như vậy sẽ nhanh chóng ủy quyền cho phương pháp Domain Model.
Sử dụng Domain Model thay vì Transaction script là bản chất của sự thay đổi mô hình mà những người hướng đối tượng nói đến rất nhiều.
Thay vì một quy trình có tất cả logic cho một hành động của người dùng, mỗi đối tượng có một phần logic liên quan đến nó. Nếu bạn chưa quen với Domain Model, việc học cách làm việc với có thể rất khó chịu vì bạn vội vã chuyển từ đối tượng này sang đối tượng khác để cố gắng tìm xem hành vi đang ở đâu.
Thật khó để nắm bắt bản chất của sự khác biệt giữa hai module bằng một ví dụ đơn giản, nhưng trong các cuộc thảo luận về các mẫu, tôi đã cố gắng làm điều đó bằng cách xây dựng một phần logic Domain đơn giản theo cả hai cách.
Cách dễ nhất để thấy sự khác biệt là nhìn vào biểu đồ trình tự cho hai cách tiếp cận. Vấn đề cốt yếu là các loại sản phẩm có khác nhau các thuật toán khác nhau để ghi nhận doanh thu trên một hợp đồng nhất định. Phương pháp tính toán phải xác định loại sản phẩm mà một hợp đồng nhất định dành cho loại sản phẩm nào, áp dụng thuật toán chính xác và sau đó tạo các đối tượng ghi nhận doanh thu để nắm bắt kết quả của phép tính.
Phương thức của Transaction Script thực hiện tất cả công việc. Các đối tượng bên dưới chỉ là Cổng dữ liệu bảng và tất cả những gì chúng làm là chuyển dữ liệu đến Transaction script.
Ngược lại cho thấy nhiều đối tượng, mỗi đối tượng chuyển tiếp một phần của hành vi sang một đối tượng chiến lược khác cho đến khi một đối tượng chiến lược tạo ra kết quả.
Giá trị của Domain Model nằm ở chỗ một khi bạn đã quen với mọi thứ, có nhiều kỹ thuật cho phép bạn xử lý ngày càng logic phức tạp theo một cách có tổ chức tốt. Khi chúng tôi nhận được ngày càng nhiều thuật toán để thuật toán tính toán ghi nhận doanh thu, chúng tôi có thể thêm các ngày bằng cách thêm các ghi nhận mới đối tượng chiến lược. Với Transaction script, chúng tôi đang thêm nhiều điều kiện hơn vào logic có điều kiện của tập lệnh. Một khi tâm trí của bạn quay cuồng với các đối tượng như của tôi, bạn sẽ thấy mình thích Domain Model ngay cả trong những trường hợp khá đơn giản.
Chi phí của Domain Model đến từ sự phức tạp của việc sử dụng nó và sự phức tạp của lớp nguồn dữ liệu của bạn. Những người mới làm quen phải mất thời gian với mô hình đối tượng phong phú để làm quen với Domain Model phong phú. Thông thường, các nhà phát triển có thể cần dành vài tháng làm việc trên một dự án sử dụng mô hình này trước khi mô hình của họ được thay đổi.
Tuy nhiên, khi bạn đã quen với Domain, bạn thường bị lây nhiễm suốt đời và nó trở nên dễ dàng làm việc với nó trong tương lai — đó là cách những người chuyên gia phân tích phần mềm sử dung. Tuy nhiên, một số ít các nhà phát triển dường như không thể tạo ra sự thay đổi.
Ngay cả khi bạn đã thay đổi, bạn vẫn phải đối phó với việc lập bản đồ cơ sở dữ liệu. Domain Model của bạn càng phong phú, việc ánh xạ của bạn tới cơ sở dữ liệu quan hệ càng phức tạp (thường là với Data Mapper). Một Dữ liệu nguồn lớp phức tạp giống như một chi phí cố định — bạn phải mất một số tiền hợp lý (nếu bạn mua) hoặc thời gian (nếu bạn xây dựng) để có được một lớp tốt, nhưng một khi bạn có nó, bạn có thể làm được rất nhiều điều với nó.
Table Module
Có một lựa chọn thứ ba để cấu trúc logic Domain, Table Module. Lúc đầu, Table Module trông giống như Domain Model vì cả hai đều có các lớp cho hợp đồng, sản phẩm và nhận biết doanh thu. Sự Quan trọng khác biệt là Domain Model có một trường hợp hợp đồng cho mỗi hợp đồng trong cơ sở dữ liệu, trong khi Table Module chỉ có một trường hợp. Một Module Bảng được thiết kế để làm việc với một Ghi Set. Do đó, ứng dụng khách của Table Module hợp đồng trước tiên sẽ đưa ra các truy vấn tới cơ sở dữ liệu để tạo thành Tập hợp bản ghi và sẽ tạo một đối tượng hợp đồng và chuyển nó cho ghi Tập hợp bản làm đối số. Sau đó, khách hàng có thể gọi các hoạt động trên hợp đồng để thực hiện nhiều việc khác nhau. Nếu nó muốn thực hiện một điều gì đó với một cá nhân hợp đồng, nó phải chuyển một ID.
Table Module theo nhiều cách là trung gian giữa Transaction script và Domain Model. Việc tổ chức Domain logic xung quanh các bảng thay vì các thủ tục thẳng cung cấp nhiều cấu trúc hơn và giúp dễ dàng tìm và loại bỏ sự trùng lặp hơn. Tuy nhiên, bạn không thể sử dụng một số kỹ thuật mà Domain Model sử dụng cho cấu trúc chi tiết hơn của logic, chẳng hạn như kế thừa, chiến lược và các mẫu OO khác.
Ưu điểm lớn nhất của Table Module là cách nó phù hợp với phần còn lại của kiến trúc.
Nhiều môi trường GUI được xây dựng để hoạt động dựa trên kết quả của truy vấn SQL được tổ chức trong Tập bản ghi. Vì Table Module cũng hoạt động trên Tập bản ghi , bạn có thể dễ dàng chạy truy vấn, thao tác với kết quả trong Table Module và chuyển dữ liệu đã thao tác sang GUI để hiển thị. Bạn cũng có thể sử dụng Table Module trên đường trở lại để xác nhận và tính toán thêm. Một số nền tảng, đặc biệt là của Microsoft COM và .NET, sử dụng kiểu phát triển này.
Cách lựa chọn Domain Logic
Vì vậy, làm thế nào để bạn chọn giữa ba Mô hình ? Đó không phải là một lựa chọn dễ dàng và
nó phụ thuộc rất nhiều vào mức độ phức tạp của logic Domain của bạn. Hình dưới là một trong những biểu đồ phi khoa học thực sự khiến tôi khó chịu trong các bài thuyết trình PowerPoint vì chúng có các trục hoàn toàn không được xác định.
Tuy nhiên, nó giúp tôi hình dung cảm giác của mình về cách so sánh giữa ba người. Với logic Domain đơn giản, Domain Model kém hấp dẫn hơn bởi vì chi phí hiểu nó và sự phức tạp của nguồn dữ liệu cộng thêm rất nhiều nỗ lực để phát triển nó sẽ không được đền đáp. Tuy nhiên, khi mức độ phức tạp của logic Domain tăng lên, các phương pháp tiếp cận khác có xu hướng chạm vào một bức tường nơi việc thêm nhiều tính năng trở nên khó khăn hơn theo cấp số nhân.
Tất nhiên, vấn đề của bạn là tìm ra vị trí mà ứng dụng của bạn nằm trên trục x. Tin tốt là tôi có thể nói rằng bạn nên sử dụng Domain Model bất cứ khi nào độ phức tạp của logic Domain của bạn lớn hơn 7,42. Tin xấu là không ai biết cách đo độ phức tạp của Domain logic. Trong thực tế, tất cả những gì bạn có thể làm là tìm một số người có kinh nghiệm có thể thực hiện phân tích ban đầu về các yêu cầu và đưa ra phán đoán.
Có một số yếu tố làm thay đổi các đường cong một chút. Một nhóm quen thuộc với Domain Model sẽ giảm chi phí ban đầu của việc sử dụng mô hình này. Nó sẽ không hạ thấp nó xuống cùng điểm xuất phát như những cái khác vì độ phức tạp của nguồn dữ liệu. Tuy nhiên, nhóm càng giỏi, tôi càng có xu hướng sử dụng Domain Module.
Tính hấp dẫn của Table Module phụ thuộc rất nhiều vào sự hỗ trợ cho cấu trúc Bộ Bản ghi chung trong môi trường của bạn. Nếu bạn có một môi trường như .NET hoặc Visual Studio, nơi có nhiều công cụ hoạt động xung quanh Bộ ghi , thì điều đó làm cho Table Module hấp dẫn hơn nhiều. Thật vậy, tôi không thấy lý do gì để sử dụng Transaction script trong môi trường .NET. Tuy nhiên, nếu không có công cụ đặc biệt cho Bộ ghi, tôi sẽ không bận tâm với Table Module
Một khi bạn đã quyết định, quyết định của bạn không hoàn toàn thành cố định, nhưng việc thay đổi sẽ khó hơn. Vì vậy, nó đáng để suy nghĩ trước để quyết định con đường đi. Nếu bạn thấy mình đã đi sai đường, thì, nếu bạn bắt đầu với Transaction script, đừng ngần ngại tái cấu trúc theo Domain Model . Tuy nhiên, nếu bạn đã bắt đầu với Domain Model , việc chuyển đến Transaction script thường ít đáng giá hơn trừ khi bạn có thể đơn giản hóa dữ liệu của mình lớp nguồn.
Ba mẫu này không phải là những lựa chọn loại trừ lẫn nhau. Thật vậy, là khá việc sử dụng Transaction script cho một số logic Domain và phổ biến Table Module hoặc Domain Model cho phần còn lại.
Service Layer
Một cách tiếp cận phổ biến trong việc xử lý logic Domain là chia lớp Domain ra làm hai. Service Layer được đặt trên Domain Model bên dưới hoặc Table Module . Thông thường, bạn chỉ nhận được điều này với Domain Model hoặc Table Module vì lớp Domain chỉ sử dụng Transaction script không đủ phức tạp để đảm bảo một lớp riêng biệt. Logic presentation tương tác với Domain hoàn toàn thông qua Service Layer, hoạt động như một API cho ứng dụng.
Ngoài việc cung cấp một API rõ ràng, Service Layer cũng là một vị trí tốt để đặt những thứ như kiểm soát và bảo mật giao dịch. Điều này cung cấp cho bạn một đơn giản mô hình về việc sử dụng từng phương thức trong Service Layer và các mô tả của nó đặc điểm giao dịch và bảo mật. Tệp thuộc tính riêng biệt là một lựa chọn phổ biến cho việc này, nhưng các thuộc tính của .NET cung cấp một cách hay để thực hiện nó trực tiếp trong mã.
Khi bạn nhìn thấy Service Layer, quyết định quan trọng là số lượng hành vi cần đưa vào nó. Trường hợp tối thiểu là làm cho Service Layer trở thành một mặt tiền để tất cả các hành vi thực đều nằm trong các đối tượng bên dưới và tất cả những gì mà Service Layer làm là chuyển tiếp các lệnh gọi từ mặt ngoài đến các đối tượng cấp thấp hơn. Trong trường hợp đó,dịch vụ Lớp cung cấp một API dễ sử dụng hơn vì nó thường được định hướng xung quanh các trường hợp sử dụng. Nó cũng tạo ra một điểm thuận tiện để thêm giao dịch trình bao bọc và kiểm tra bảo mật.
Ở một khía cạnh khác, hầu hết logic nghiệp vụ được đặt trong Transaction script bên trong Service Layer. Các đối tượng Domain cơ bản rất đơn giản; nếu đó là Domain Model thì nó sẽ là 1-1 với cơ sở dữ liệu và do đó bạn có thể sử dụng lớp nguồn dữ liệu đơn giản hơn như Active Record .
Giữa những lựa chọn thay thế này là sự kết hợp đồng đều hơn về hành vi: kiểu thực thể-bộ điều khiển. Vấn đề ở đây là phải có logic dành riêng cho một đơn lẻ giao dịch hoặc trường hợp sử dụng được đặt trong Transaction script , thường được gọi là controller hoặc service.Tôi không nói rằng bạn không bao giờ nên có các đối tượng dịch vụ chứa logic nghiệp vụ, nhưng bạn không nhất thiết phải tạo một lớp cố định của chúng.
Các đối tượng dịch vụ thủ tục đôi khi có thể là một cách rất hữu ích để tính toán logic,
nhưng tôi có xu hướng sử dụng chúng khi cần thiết hơn là một lớp kiến trúc. Do đó, sở thích của tôi là có Service Layer mỏng nhất mà bạn có thể, nếu bạn thậm chí cần một lớp. Cách tiếp cận thông thường của tôi là giả định rằng tôi không cần một cái và chỉ thêm nó nếu có vẻ như ứng dụng cần nó. Tuy nhiên, tôi biết nhiều nhà thiết kế giỏi luôn sử dụng Service Layer với một chút logic hợp lý.
