THE DOMAIN MODEL

Tôi đã gồm một nội dung bài viết về Domain Drive Development (DDD) – First thought để “đặt vấn đề” cho DDD, các chúng ta cũng có thể tham khảo ở kia trước. Trong phạm vi nội dung bài viết này, tôi sẽ tham khảo và mô tả lại từ bài xích viết Domain-Drive Design của tác giả herbertograca.

Bạn đang xem: The domain model

Domain-Drive Design vày Eric Evans tạo nên trong cuốn sách nổi tiếng của ông về Domain-Driven Design: Tackling Complexity in the Heart of Software, xuất bản năm 2003. Cuốn sách của Eric Evans là chìa khóa ưng thuận hóa nhiều khái niệm phân phát triển ứng dụng hiện nay.


*

Eric Evans, 2003

BOUNDED CONTEXTS

Trong một vận dụng doanh nghiệp, tất cả thể có tương đối nhiều model, những khái niệm tương tự như số lượng và form size của team thao tác làm việc trên codebase là siêu lớn. Điều này mang lại cho họ hai vấn đề:

Các developer làm việc trên codebase càng lớn thì sẽ càng khó nhấn thức với hiểu đúng về phần lớn gì đầy đủ đoạn mã sẽ làm, và bởi vì đó rất có thể tạo ra bug, gây khó khăn trong câu hỏi debug, phát âm đúng và ra quyết định được gia công theo vắt nào.Các nhiều developer làm việc trên cùng một codebase, càng khó khăn hơn để bắt tay hợp tác và tất cả một tầm nhìn bao quát về nghệ thuật và nhiệm vụ của ứng dụng.

Nói cách khác, sẽ là 2 sự việc lớn cần xử lý khi thao tác làm việc với những ứng dụng tầm khuôn khổ enterprise.

Giải pháp thông thường cho một sự việc lớn là chia nhỏ dại nó thành đa số phần nhỏ dại hơn, hay còn được gọi là “bounded contexts”. Vị trí mỗi phần phục cho những đối tượng người sử dụng người dùng khác nhau. Nói cách khác, vào 1 hệ thống phần mềm doanh nghiệp, nơi mà khối hệ thống sẽ giao hàng cho khôn xiết nhiều đối tượng người tiêu dùng người sử dụng khác nhau, việc chúng ta nên làm cho là chia nhỏ dại hệ thống đó ra thành hồ hết hệ thống bé dại hơn, lẻ tẻ về nhiệm vụ, và đối tượng người dùng. Ví dụ khối hệ thống nhân sự, kế toán, tiền lương. Từng hệ thống có 1 ngữ cảnh riêng hotline là “bounded contexts”, khu vực mà nó khối hệ thống con kia chỉ bao gồm hiểu biết về ngữ cảnh, nghiệp vụ nó đảm nhiệm.

Two subsystems commonly serve very different user communities.

Eric Evans 2014, Domain-Driven thiết kế Reference

Các bounded contexts khẳng định một văn cảnh áp dụng 1 phần riêng biệt của quy mô nghiệp vụ. Việc cô lập này có thể đạt được bằng cách tách các logic kỹ thuật, tách biệt codebase, bóc tách biệt giản đồ cơ sở tài liệu (database schema) cùng về tổ chức team. Nấc độ xa lánh bounded context, như thường lệ, phụ thuộc vào thực trạng thực tế: yêu cầu và khả năng chúng ta có.

Một điểm thú vị, đây không phải là 1 khái niệm trọn vẹn mới. Ivar Jacobson vẫn viết về các hệ thống con (subsystems) trong cuốn sách của chính mình (Object-Oriented Software Engineering: A Use Case Driven Approach), trở về vào năm 1992, mười một năm ngoái Eric Evans!

Ivar Jacobson, 1992

Khi đó, ông đã có một vài phát minh rất rõ ràng về chủ thể này:

Hệ thống bởi vậy gồm 1 số các khối hệ thống con rất có thể chứa các hệ thống con của chủ yếu nó. Ở dưới cùng của phân cấp vậy nên là các đối tượng người dùng phân tích (analysis objects). Các khối hệ thống con là một phương pháp để cấu trúc khối hệ thống cho việc phát triển và bảo trì.Nhiệm vụ của các hệ thống con là đóng gói các đối tượng sao để triển khai giảm đi sự phức tạp.Tất cả các đối tượng người tiêu dùng đảm nhiệm các phần cụ thể của tính năng sẽ được để trong thuộc một khối hệ thống conMục đích là để có một lắp kết tác dụng mạnh mẽ trong một subsystem cùng một sự liên kết lỏng lẽo giữa những subsystem (ngày nay được gọi là low coupling and high cohesion) nên giỏi hơn phải được sử dụng bởi chỉ một actor, vì đổi khác thường được gây nên bởi một actor.<…> bắt đầu bằng phương pháp đặt các đối tượng người sử dụng điều khiển vào một subsystem, và kế tiếp đặt các đối tượng thực thể liên kết chặt chẽ (strongly coupled) với các đối tượng người sử dụng giao diện (interface objects) trong cùng một subsystem.Tất cả các đối tượng người sử dụng có thêm kết tác dụng mạnh mẽ (strong mutual functional coupling) sẽ tiến hành đặt trong và một subsystem <…>Liệu những đổi khác trong một đối tượng dẫn cho những thay đổi trong đối tượng người tiêu dùng kia? (Điều này bây chừ được hotline là chế độ The Common Closure Principle – Classes được xuất phiên bản bởi Robert C. Martin trong bài bác báo “Granularity” năm 1996, 4 năm tiếp theo cuốn sách Ivar Jacobson)Liệu bọn chúng có tiếp xúc với cùng một actor?Có cần cả hai đều nhờ vào vào một đối tượng người tiêu dùng thứ ba, ví dụ như một interface object hay là một entity? Liệu một đối tượng người tiêu dùng thực hiện một số vận động trên đối tượng người sử dụng kia? (Điều này được call là qui định The Common Reuse Principle – Classes, được thực hiện cùng nhau được đóng góp gói cùng mọi người trong nhà của Robert C. Martin trong bài báo “Granularity” năm 1996, 4 năm tiếp theo cuốn sách Ivar Jacobson)Một tiêu chí khác mang lại việc phân chia là phải gồm ít thông tin trao đổi giữa các hệ thống con khác biệt càng tốt (low coupling)Đối với những dự án lớn, hoàn toàn có thể có các tiêu chí khác mang đến phân khối hệ thống con, ví dụ:Các nhóm phát triển khác nhau có năng lượng hoặc mối cung cấp lực khác biệt và hoàn toàn có thể phân phối các quá trình phát triển cân xứng (các nhóm cũng hoàn toàn có thể được tách biệt về khía cạnh địa lý)Trong một môi trường xung quanh phân tán, một hệ thống phụ hoàn toàn có thể được yêu mong ở mỗi logical node (SOA, website services và micro services) nếu như một sản phẩm hiện có rất có thể được áp dụng trong hệ thống này, điều này hoàn toàn có thể được xem là một subsystem (các libraries cơ mà hệ thống nhờ vào vào, ví dụ như ORM).

Xem thêm: Top 11 Mẫu Thuyết Minh Về Nón Lá Việt Nam Hay Nhất (5 Mẫu Chọn Lọc)

ANTI-CORRUPTION LAYER

Một Anti-Corruption Layer cơ bạn dạng là một middleware thân hai hệ thống con. Nó được áp dụng để xa lánh hai khối hệ thống con, làm cho chúng phụ thuộc vào vào layer này nỗ lực vì phụ thuộc trực tiếp vào nhau. Bằng cách này, nếu bọn họ tái cấu trúc hoặc gắng thế hoàn toàn một vào các khối hệ thống con thì họ sẽ chỉ phải update layer này để các khối hệ thống con không giống không bị hình ảnh hưởng.

Điều này quan trọng hữu ích khi tất cả một khối hệ thống mới mà bọn họ cần cần tích phù hợp với một hệ thống có sẵn. Để không để những hệ thống cũ chịu đựng sự tác động từ việc thêm new các hệ thống con mới, bọn họ tạo ra một Anti-Corruption Layer sẽ điều chỉnh API của hệ thống cũ cho các yêu cầu của khối hệ thống con mới.

Có 3 mối thân yêu chính:

Điều chỉnh các API hệ thống con với gần như gì những client subsystems cần;Translate data và commands giữa các khối hệ thống con;Thiết lập điều đình (communication) theo một hoặc nhiều hướng, nếu như cần

Eric Evans, 2003

Đây là 1 trong những kỹ thuật được sử dụng hợp lý khi họ không kiểm soát và điều hành một hoặc toàn bộ các khối hệ thống con, tuy thế cũng có thể sử dụng nó khi chúng ta kiểm soát toàn bộ các khối hệ thống con liên quan, ngay cả khi chúng được thiết kế tốt nhưng đơn giản có các mã sản phẩm rất khác nhau và chúng ta muốn ngăn ngừa sự thất thoát từ mã sản phẩm này sang mã sản phẩm khác (thay thay đổi một hệ thống con để tương xứng với nhu yếu của một khối hệ thống con khác).

SHARED KERNEL

Trong một trong những trường hợp, mặc kệ mong ước ao của họ để có các thành phần bóc biệt trọn vẹn và bóc rời, vẫn có một vài trường đúng theo buộc ta phải tách bóc một số domain code ra để share cho các component không giống sử dụng.

Điều này sẽ chất nhận được các component vẫn giữ được tính phân tách và độc lập với những component khác tuy nhiên sử dụng thông thường những mã chia sẻ cùng (shared code), ta gọi các mã share này với cái thương hiệu “shared kernel”.

Trường đúng theo ví dụ, với những events được kích hoạt bởi một component và lắng nghe bởi một hoặc một số trong những component khác. Và giống như cho các service interfaces and thậm chí là là các entities.

Tuy nhiên, bắt buộc giữ phần Shared Kernel này càng nhỏ dại càng tốt, và cẩn trọng khi đổi khác nó vì bạn cũng có thể một cách vô tình gây tác động đến những chỗ khác đang áp dụng nó. Điều quan trọng là mã trong Shared Kernel sẽ không còn nên bị biến hóa nếu không tồn tại sự tham gia và hiểu biết của tất cả các nhóm cải cách và phát triển khác áp dụng nó.

GENERIC SUBDOMAIN

Một Subdomain là một phần rất khác hoàn toàn của domain. Generic Subdomain là 1 trong những Subdomain không liên quan đến áp dụng của bọn họ mà có thể được thực hiện trong ngẫu nhiên ứng dụng nào tương tự.

Vì vậy, nếu gồm một vận dụng có một trong những phần của nó là về finance, gồm lẽ bạn cũng có thể sử dụng một thư viện finance hiện tất cả trong ứng dụng. Tuy nhiên dù sao đi nữa, ngay cả khi ko thể áp dụng thư viện hiện gồm và yêu cầu xây dựng riêng biệt của chúng ta, nếu như nó là một Generic Subdomain thì đó không phải là chuyển động cốt lõi với nó phải phải được đánh giá là quan trọng nhưng ko quan trọng. Đây không hẳn là phần quan trọng nhất trong vận dụng nên chưa hẳn là nơi các chuyên gia giỏi duy nhất nên triệu tập và thậm chí phải rõ ràng bên phía ngoài mã mối cung cấp chính, nó hoàn toàn có thể được cài đặt với một công cụ thống trị sự dựa vào (dependency management tool).

KẾT LUẬN

Các có mang DDD tôi đã lựa chọn để tiếp cận tại đây là, một lượt nữa, đa số về single responsibility, low coupling, high cohesion, isolating súc tích để ứng dụng của bọn họ trở buộc phải nhất quán, thuận tiện và hối hả hơn để biến hóa và say mê ứng với nhu cầu của doanh nghiệp.

SOURCES

1992 – Ivar Jacobson – Object-Oriented Software Engineering: A use case driven approach

1996 – Robert C. Martin – Granularity

2003 – Eric Evans – Domain-Driven Design: Tackling Complexity in the Heart of Software

2014 – Eric Evans – Domain-Driven design Reference

Đây là bài viết trong loạt nội dung bài viết về “Tổng quan lại về sự phát triển của phong cách xây dựng phần mềm“. Đây là loạt bài viết chủ yếu giới thiệu về một số quy mô kiến trúc phần mềm hay nói đúng hơn là việc phát triển của chúng qua từng giai đoạn, thông qua đó giúp họ có ánh nhìn tổng quát, up-to-date với là roadmap để bước đầu hành trình chinh phục (đào sâu) nhân loại của những phiên bản thiết kế với phương châm là gần như kỹ sư và kiến trúc sư phần mềm đam mê với nghề.