Ai đó có thể giải thích sự khác biệt giữa tên miền và dịch vụ ứng dụng bằng cách cung cấp một số ví dụ? Và, nếu một dịch vụ là một dịch vụ tên miền, tôi có nên triển khai thực tế dịch vụ này trong tổ hợp tên miền không và nếu có, tôi cũng sẽ đưa kho lưu trữ vào dịch vụ tên miền đó chứ? Một số thông tin sẽ thực sự hữu ích.
Câu trả lời:
Dịch vụ có 3 loại: Dịch vụ tên miền , Dịch vụ ứng dụng và Dịch vụ cơ sở hạ tầng .
Giữ các dịch vụ miền cùng với các đối tượng miền của bạn là hợp lý - tất cả chúng đều tập trung vào logic miền. Và vâng, bạn có thể tiêm Kho lưu trữ vào Dịch vụ của mình.
Dịch vụ ứng dụng thường sẽ sử dụng cả Dịch vụ miền và Kho lưu trữ để xử lý các yêu cầu bên ngoài.
Mong rằng sẽ giúp!
(Nếu bạn không thích đọc, có một bản tóm tắt ở phía dưới :-)
Tôi cũng đã đấu tranh với định nghĩa chính xác của các dịch vụ ứng dụng. Mặc dù câu trả lời của Vijay rất hữu ích cho quá trình suy nghĩ của tôi một tháng trước, tôi đã không đồng ý với một phần của nó.
Có rất ít thông tin về các dịch vụ ứng dụng. Các chủ đề như gốc tổng hợp, kho lưu trữ và dịch vụ miền được thảo luận rộng rãi, nhưng các dịch vụ ứng dụng chỉ được đề cập ngắn gọn hoặc bỏ qua hoàn toàn.
Bài viết của Tạp chí MSDN Giới thiệu về Thiết kế hướng tên miền mô tả các dịch vụ ứng dụng như một cách để chuyển đổi và / hoặc hiển thị mô hình miền của bạn cho các máy khách bên ngoài, ví dụ như dịch vụ WCF. Đây là cách Vijay mô tả các dịch vụ ứng dụng quá. Từ quan điểm này, các dịch vụ ứng dụng là một giao diện cho miền của bạn .
Các bài viết của Jeffrey Palermo về Kiến trúc hành tây (phần một , hai và ba ) là một bài đọc tốt. Anh coi các dịch vụ ứng dụng là các khái niệm cấp ứng dụng , như phiên của người dùng. Mặc dù điều này gần với sự hiểu biết của tôi về các dịch vụ ứng dụng, nhưng nó vẫn không phù hợp với suy nghĩ của tôi về chủ đề này.
Tôi đã nghĩ về các dịch vụ ứng dụng như các phụ thuộc được cung cấp bởi ứng dụng . Trong trường hợp này, ứng dụng có thể là ứng dụng máy tính để bàn hoặc dịch vụ WCF.
Thời gian cho một ví dụ. Bạn bắt đầu với tên miền của bạn. Tất cả các thực thể và bất kỳ dịch vụ miền nào không phụ thuộc vào tài nguyên bên ngoài đều được triển khai tại đây. Bất kỳ khái niệm miền phụ thuộc vào tài nguyên bên ngoài được xác định bởi một giao diện. Đây là một bố trí giải pháp có thể (tên dự án in đậm):
Giải pháp của tôi
- My. Productt.Core (My. SẢNt.dll)
- Dịch vụ tên miền
Dịch vụ IExchangeRateSate
Sản phẩm
Sản phẩm đạt yêu cầu
IP sinh sản
Các lớp Productvà ProductFactoryđã được thực hiện trong hội đồng cốt lõi. Đây IProductRepositorylà một cái gì đó có thể được hỗ trợ bởi một cơ sở dữ liệu. Việc thực hiện điều này không phải là mối quan tâm của miền và do đó được xác định bởi một giao diện.
Hiện tại, chúng tôi sẽ tập trung vào IExchangeRateService. Logic nghiệp vụ cho dịch vụ này được triển khai bởi một dịch vụ web bên ngoài. Tuy nhiên, khái niệm của nó vẫn là một phần của miền và được thể hiện bằng giao diện này.
Việc thực hiện các phụ thuộc bên ngoài là một phần của cơ sở hạ tầng của ứng dụng:
Giải pháp của tôi
+ My. Productt.Core (My. SẢNt.dll)
- My.Sản phẩm. Cơ sở hạ tầng (My. Sản phẩm. Cơ sở hạ tầng.dll)
- Dịch vụ tên miền
XEExchangeRateService
SqlServerSản phẩm
XEExchangeRateServicetriển khai IExchangeRateServicedịch vụ tên miền bằng cách liên lạc với xe.com . Việc triển khai này có thể được sử dụng bởi các ứng dụng sử dụng mô hình miền của bạn, bằng cách bao gồm cả cơ sở hạ tầng.
Lưu ý rằng tôi chưa đề cập đến các dịch vụ ứng dụng. Bây giờ chúng ta sẽ xem xét chúng. Giả sử chúng tôi muốn cung cấp một IExchangeRateServicetriển khai sử dụng bộ đệm để tra cứu nhanh. Các phác thảo của lớp trang trí này có thể trông như thế này.
public class CachingExchangeRateService : IExchangeRateService
{
private IExchangeRateService service;
private ICache cache;
public CachingExchangeRateService(IExchangeRateService service, ICache cache)
{
this.service = service;
this.cache = cache;
}
// Implementation that utilizes the provided service and cache.
}
Chú ý ICachetham số? Khái niệm này không phải là một phần của miền của chúng tôi, vì vậy nó không phải là một dịch vụ tên miền. Đây là một dịch vụ ứng dụng . Đó là một sự phụ thuộc của cơ sở hạ tầng của chúng tôi có thể được cung cấp bởi ứng dụng. Hãy giới thiệu một ứng dụng thể hiện điều này:
Giải pháp của tôi
- My. Productt.Core (My. SẢNt.dll)
- Dịch vụ tên miền
Dịch vụ IExchangeRateSate
Sản phẩm
Sản phẩm đạt yêu cầu
IP sinh sản
- My.Sản phẩm. Cơ sở hạ tầng (My. Sản phẩm. Cơ sở hạ tầng.dll)
- Dịch vụ ứng dụng
ICache
- Dịch vụ tên miền
Bộ nhớ đệmExchangeRateService
XEExchangeRateService
SqlServerSản phẩm
- My. SẢNt.WcfService (My. SẢNt.WcfService.dll)
- Dịch vụ ứng dụng
MemcachedCache
IMyWcfService.cs
+ MyWcfService.svc
+ Web.config
Tất cả điều này kết hợp với nhau trong ứng dụng như thế này:
// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);
ServiceLocator.For<IExchangeRateService>().Use(cachingService);
Một ứng dụng hoàn chỉnh bao gồm ba lớp chính:
Lớp miền chứa các thực thể miền và các dịch vụ miền độc lập. Bất kỳ khái niệm miền (điều này bao gồm các dịch vụ miền, nhưng cũng có kho lưu trữ) phụ thuộc vào tài nguyên bên ngoài, được xác định bởi các giao diện.
Lớp cơ sở hạ tầng chứa việc thực hiện các giao diện từ lớp miền. Những triển khai này có thể giới thiệu các phụ thuộc không thuộc miền mới phải được cung cấp cho ứng dụng. Đây là các dịch vụ ứng dụng và được đại diện bởi các giao diện.
Lớp ứng dụng chứa việc thực hiện các dịch vụ ứng dụng. Lớp ứng dụng cũng có thể chứa các triển khai bổ sung của giao diện miền, nếu các triển khai được cung cấp bởi lớp cơ sở hạ tầng là không đủ.
Mặc dù phối cảnh này có thể không phù hợp với định nghĩa chung về dịch vụ DDD, nhưng nó tách biệt miền khỏi ứng dụng và cho phép bạn chia sẻ lắp ráp miền (và cơ sở hạ tầng) giữa một số ứng dụng.
IExchangeRateServicegiao diện? Đây là một khái niệm miền, tức là một cái gì đó được bao gồm trong ngôn ngữ phổ biến của khách hàng của bạn. Các phần khác trong miền của bạn có thể phụ thuộc vào dịch vụ này, đó là lý do tại sao giao diện của nó được xác định trong lớp miền. Nhưng vì việc triển khai của nó liên quan đến một dịch vụ web bên ngoài, lớp triển khai nằm trong lớp cơ sở hạ tầng. Bằng cách này, lớp miền chỉ liên quan đến logic kinh doanh.
ExchangeRateví dụ, trong đó có một loại tiền tệ cơ bản, một loại tiền tệ và giá trị tỷ giá hối đoái giữa hai loại tiền tệ này. Các giá trị liên quan chặt chẽ này biểu thị khái niệm 'tỷ giá hối đoái' từ miền, vì vậy các giá trị này nằm trong lớp miền. Mặc dù nó có vẻ giống như một DTO đơn giản, nhưng trong DDD, nó được gọi là Đối tượng Giá trị và nó có thể chứa logic nghiệp vụ bổ sung để so sánh hoặc chuyển đổi các thể hiện.
Tài nguyên tốt nhất giúp tôi hiểu được sự khác biệt giữa Dịch vụ ứng dụng và Dịch vụ miền là việc triển khai java ví dụ về hàng hóa của Eric Evans, được tìm thấy ở đây . Nếu bạn không tải nó, bạn có thể kiểm tra các phần bên trong của RoutingService (Dịch vụ tên miền) và Dịch vụ đặt phòng, CargoInspectionService (là Dịch vụ ứng dụng).
Khoảnh khắc 'aha của tôi được kích hoạt bởi hai điều:
Đọc mô tả về Dịch vụ trong liên kết trên, chính xác hơn là câu này:
Các dịch vụ miền được thể hiện dưới dạng ngôn ngữ phổ biến và các loại miền, tức là các đối số phương thức và các giá trị trả về là các lớp miền thích hợp.
Đọc bài đăng trên blog này , đặc biệt là phần này:
Những gì tôi tìm thấy một sự trợ giúp lớn trong việc tách táo ra khỏi cam là suy nghĩ về quy trình làm việc của ứng dụng. Tất cả logic liên quan đến quy trình làm việc của ứng dụng thường kết thúc là Dịch vụ ứng dụng được đưa vào Lớp ứng dụng, trong khi các khái niệm từ miền dường như không phù hợp khi các đối tượng mô hình kết thúc hình thành một hoặc nhiều Dịch vụ miền.
Dịch vụ tên miền là phần mở rộng của tên miền. Nó chỉ nên được nhìn thấy trong bối cảnh của tên miền. Đây không phải là một số hành động của người dùng như ví dụ đóng tài khoản hoặc một cái gì đó. Dịch vụ tên miền phù hợp với nơi không có nhà nước. Nếu không, nó sẽ là một đối tượng miền. Dịch vụ miền thực hiện điều gì đó có ý nghĩa chỉ khi được thực hiện với các cộng tác viên khác (đối tượng miền hoặc các dịch vụ khác). Và ý nghĩa đó là trách nhiệm của một lớp khác.
Dịch vụ ứng dụng là lớp khởi tạo và giám sát sự tương tác giữa các đối tượng và dịch vụ miền. Luồng nói chung là như thế này: lấy đối tượng miền (hoặc đối tượng) từ kho lưu trữ, thực hiện một hành động và đặt nó (chúng) trở lại đó (hoặc không). Nó có thể làm nhiều hơn - ví dụ, nó có thể kiểm tra xem một đối tượng miền có tồn tại hay không và đưa ra các ngoại lệ tương ứng. Vì vậy, nó cho phép người dùng tương tác với ứng dụng (và đây có lẽ là tên của nó bắt nguồn từ đó) - bằng cách thao tác các đối tượng và dịch vụ miền. Các dịch vụ ứng dụng thường đại diện cho tất cả các trường hợp sử dụng có thể. Có lẽ điều tốt nhất bạn có thể làm trước khi nghĩ về tên miền là tạo giao diện dịch vụ ứng dụng, điều sẽ cho bạn cái nhìn sâu sắc hơn nhiều về những gì bạn đang thực sự cố gắng làm. Có kiến thức như vậy cho phép bạn tập trung vào tên miền.
Các kho lưu trữ nói chung có thể được đưa vào các dịch vụ miền nhưng đây là tình huống khá hiếm. Mặc dù vậy, lớp ứng dụng là người thực hiện nó hầu hết thời gian.
Từ Sách đỏ (Triển khai thiết kế hướng tên miền, của Vaughn Vernon), đây là cách tôi hiểu các khái niệm:
Các đối tượng miền ( thực thể và đối tượng giá trị ) đóng gói hành vi được yêu cầu bởi miền (phụ), làm cho nó tự nhiên, biểu cảm và dễ hiểu.
Các dịch vụ miền đóng gói các hành vi như vậy không phù hợp với một đối tượng miền duy nhất . Ví dụ, một thư viện sách cho vay một Bookđến một Client(tương ứng với Inventorynhững thay đổi) có thể làm như vậy từ một dịch vụ tên miền.
Các dịch vụ ứng dụng xử lý luồng các trường hợp sử dụng, bao gồm mọi mối quan tâm bổ sung cần thiết trên đầu trang của tên miền. Nó thường phơi bày các phương thức như vậy thông qua API của nó, để tiêu thụ bởi các khách hàng bên ngoài. Để xây dựng theo ví dụ trước, dịch vụ ứng dụng của chúng tôi có thể hiển thị một phương thức LendBookToClient(Guid bookGuid, Guid clientGuid):
Client.Book.Clientvà Book) để xử lý logic miền thực tế cho mượn sách cho khách hàng. Chẳng hạn, tôi tưởng tượng rằng việc xác nhận tính khả dụng của cuốn sách chắc chắn là một phần của logic miền.Một dịch vụ ứng dụng thường có một luồng rất đơn giản. Các luồng dịch vụ ứng dụng phức tạp thường chỉ ra rằng logic miền đã bị rò rỉ ra khỏi miền.
Như bạn có thể thấy, mô hình miền vẫn rất sạch sẽ theo cách này, và dễ hiểu và thảo luận với các chuyên gia tên miền, bởi vì nó chỉ chứa các mối quan tâm kinh doanh thực tế của chính nó. Mặt khác , luồng ứng dụng cũng dễ quản lý hơn, vì nó được giải tỏa các mối quan tâm về miền, và trở nên súc tích, và đơn giản.
Dịch vụ miền: Các phương thức không thực sự phù hợp với một thực thể hoặc yêu cầu quyền truy cập vào kho lưu trữ được chứa trong các dịch vụ miền. Lớp dịch vụ miền cũng có thể chứa logic miền của chính nó và là một phần của mô hình miền như các thực thể và các đối tượng giá trị.
Dịch vụ ứng dụng: Dịch vụ ứng dụng là một lớp mỏng nằm phía trên mô hình miền và điều phối hoạt động của ứng dụng. Nó không chứa logic kinh doanh và không giữ trạng thái của bất kỳ thực thể nào; tuy nhiên, nó có thể lưu trữ trạng thái của một giao dịch quy trình công việc. Bạn sử dụng dịch vụ Ứng dụng để cung cấp API vào mô hình miền bằng cách sử dụng mẫu nhắn tin Yêu cầu-Trả lời.
Millett, C (2010). Mẫu thiết kế ASP.NET chuyên nghiệp. Nhà xuất bản Wiley. 92.
Dịch vụ miền : Một dịch vụ thể hiện logic nghiệp vụ không phải là một phần của bất kỳ Root tổng hợp nào.
Bạn có 2 Tổng hợp:
Product trong đó có tên và giá cả.Purchase trong đó có ngày mua, danh sách các sản phẩm được đặt hàng với số lượng và giá sản phẩm tại thời điểm đó và phương thức thanh toán.Checkout không phải là một phần của hai mô hình này và là khái niệm trong doanh nghiệp của bạn.
Checkoutcó thể được tạo như một Dịch vụ miền, tìm nạp tất cả sản phẩm và tính tổng giá, trả tổng số bằng cách gọi một Dịch vụ miền khác PaymentServicevới một phần triển khai của Cơ sở hạ tầng và chuyển đổi thành Purchase.Dịch vụ ứng dụng : Một dịch vụ "phối hợp" hoặc thực hiện các phương thức Miền. Điều này có thể đơn giản như chỉ là Trình điều khiển của bạn.
Đây là nơi bạn thường làm:
public String createProduct(...some attributes) {
if (productRepo.getByName(name) != null) {
throw new Exception();
}
productId = productRepository.nextIdentity();
product = new Product(productId, ...some attributes);
productRepository.save(product);
return productId.value();
// or Product itself
// or just void if you dont care about result
}
public void renameProduct(productId, newName) {
product = productRepo.getById(productId);
product.rename(newName);
productRepo.save(product);
}
Bạn có thể xác nhận ở đây như kiểm tra nếu a Productlà duy nhất. Trừ khi Productlà duy nhất là một bất biến thì đó sẽ là một phần của Dịch vụ miền có thể được gọi UniqueProductCheckervì nó không thể là một phần của Productlớp và nó tương tác với nhiều Tập hợp.
Dưới đây là ví dụ đầy đủ về dự án DDD: https://github.com/VaughnVernon/IDDD_Samples
Bạn có thể tìm thấy rất nhiều ví dụ về Dịch vụ ứng dụng và một vài Dịch vụ miền
Hãy nghĩ rằng Dịch vụ miền là một đối tượng thực hiện logic nghiệp vụ hoặc logic liên quan đến quy tắc kinh doanh trên các đối tượng miền và logic này khó phù hợp với cùng các đối tượng miền và cũng không gây ra thay đổi trạng thái của dịch vụ miền (dịch vụ miền là đối tượng không có một "trạng thái" hoặc tốt hơn không có trạng thái có ý nghĩa kinh doanh) nhưng cuối cùng chỉ thay đổi trạng thái của các đối tượng miền hoạt động.
Mặc dù Dịch vụ Ứng dụng triển khai logic mức ứng dụng như tương tác người dùng, xác thực đầu vào, logic không liên quan đến kinh doanh mà liên quan đến các mối quan tâm khác: xác thực, bảo mật, gửi email, v.v., hạn chế sử dụng các dịch vụ được hiển thị bởi các đối tượng miền.
Một ví dụ về điều này có thể là kịch bản sau đây chỉ được nghĩ đến để giải thích: chúng ta phải thực hiện một ứng dụng tiện ích rất nhỏ thực hiện một thao tác đơn giản, đó là "bật đèn, khi ai đó mở cửa phòng của một ngôi nhà để vào vào và tắt đèn khi đóng cửa thoát ra khỏi phòng ".
Đơn giản hóa rất nhiều, chúng tôi chỉ xem xét 2 thực thể miền: Doorvà Lamp, mỗi thực thể có 2 trạng thái, tôn trọng open/closedvà on/offvà các phương thức cụ thể để vận hành các thay đổi trạng thái trên chúng.
Trong trường hợp này, chúng tôi cần một dịch vụ miền thực hiện thao tác cụ thể bật đèn khi ai đó mở cửa từ bên ngoài để vào phòng, bởi vì cửa và các đối tượng đèn không thể thực hiện logic này theo cách mà chúng tôi cho là phù hợp với bản chất của họ .
Chúng ta có thể gọi dịch vụ miền của mình là DomoticDomainServicevà thực hiện 2 phương thức: OpenTheDoorAndTurnOnTheLightvà CloseTheDoorAndTurnOffTheLight, hai phương thức này tôn trọng thay đổi trạng thái của cả hai đối tượng Doorvà Lampđến open/onvà closed/off.
Trạng thái nhập hoặc thoát khỏi một phòng không có trong đối tượng dịch vụ miền và trong các đối tượng miền, nhưng sẽ được triển khai dưới dạng tương tác người dùng đơn giản bởi một dịch vụ ứng dụng, mà chúng tôi có thể gọi HouseService, thực hiện một số trình xử lý sự kiện như onOpenRoom1DoorToEntervà onCloseRoom1DoorToExit, v.v. cho mỗi phòng (đây chỉ là một ví dụ để giải thích mục đích ..) , điều đó sẽ liên quan đến các phương thức dịch vụ miền gọi để thực hiện hành vi tham dự (chúng tôi chưa xem xét thực thể Roomvì đây chỉ là một ví dụ) .
Ví dụ này, cho đến nay là một ứng dụng trong thế giới thực được thiết kế tốt, có mục đích duy nhất (như nhiều lần nói hơn) để giải thích Dịch vụ Miền là gì và sự khác biệt của nó với Dịch vụ Ứng dụng, hy vọng nó rõ ràng và hữu ích.