Tôi đã có một nội dung bài viết về Domain Drive Development (DDD) – First thought để “đặt vấn đề” mang đến DDD, các bạn 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à diễn đạt lại từ bài viết Domain-Drive Design của người sáng tác herbertograca.

Bạn đang xem: Domain driven design là gì

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


*

Eric Evans, 2003

BOUNDED CONTEXTS

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

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

Nói bí quyết khác, sẽ là 2 vụ việc lớn cần giải quyết và xử lý khi thao tác với các ứng dụng tầm kích thước enterprise.

Giải pháp thông thường cho một sự việc lớn là chia bé dại nó thành đông đảo phần nhỏ tuổi hơn, hay nói một cách khác là “bounded contexts”. Chỗ mỗi phần phục mang đến những đối tượng người tiêu dùng người cần sử dụng khác nhau. Nói giải pháp khác, vào 1 khối hệ thống phần mượt doanh nghiệp, vị trí mà hệ thống sẽ ship hàng cho cực kỳ nhiều đối tượng người sử dụng khác nhau, việc bọn họ nên làm cho là chia bé dại hệ thống kia ra thành phần nhiều hệ thống nhỏ dại hơn, riêng biệt về nhiệm vụ, và đối tượng người dù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 call là “bounded contexts”, địa điểm mà nó hệ thống con kia chỉ có 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 design Reference

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

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

Ivar Jacobson, 1992

Khi đó, ông đã bao gồm một vài ý tưởng rất cụ thể về chủ đề này:

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

ANTI-CORRUPTION LAYER

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

Điều này quan trọng hữu ích khi tất cả một hệ thống mới mà bọn họ cần nên tích hợp với một khối hệ thống có sẵn. Để không để những hệ thống cũ chịu 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ẽ kiểm soát và điều chỉnh API của hệ thống cũ đến các nhu yếu của khối hệ thống con mới.

Có 3 mối quan tâm chính:

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

Eric Evans, 2003

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

SHARED KERNEL

Trong một trong những trường hợp, bất chấp mong ý muốn của bọn họ để có các thành phần tách bóc biệt trọn vẹn và bóc tách rời, vẫn có một số trong những trường phù hợp buộc ta phải bóc tách một số domain code ra để chia sẻ cho nhiều component khác sử dụng.

Điều này sẽ cho phép các component vẫn giữ được tính phân bóc tách và chủ quyền với những component khác mặc dù sử dụng thông thường những mã chia sẻ cùng (shared code), ta gọi những mã chia sẻ này với cái thương hiệu “shared kernel”.

Trường thích hợp ví dụ, với các events được kích hoạt vì một component với lắng nghe do một hoặc một vài component khác. Và tựa như cho những service interfaces and thậm chí là những entities.

Tuy nhiên, bắt buộc giữ phần Shared Kernel này càng nhỏ càng tốt, và cẩn thận khi chuyển đổi nó vì chúng ta có thể một phương pháp vô tình gây tác động đến những chỗ khác đang sử dụng nó. Điều đặc biệt là mã trong Shared Kernel sẽ không còn nên bị đổi khác nếu không có sự tham gia cùng hiểu biết của toàn bộ các nhóm phát triển khác thực hiện nó.

GENERIC SUBDOMAIN

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

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

KẾT LUẬN

Các định nghĩa DDD tôi đã chọn để tiếp cận ở chỗ này là, một lượt nữa, hầu hết về single responsibility, low coupling, high cohesion, isolating xúc tích để vận dụng của bọn họ trở yêu cầu nhất quán, dễ dãi và nhanh chóng hơn để chuyển đổi và mê thích ứng với nhu cầu của doanh nghiệp.

Xem thêm: Chế Độ Fridge Là Gì, Nghĩa Của Từ Fridge, Hướng Dẫn Cách Chỉnh Nhiệt Độ Tủ Lạnh

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 thiết kế 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ự cải cách và phát triển của phong cách thiết kế phần mềm“. Đây là loạt nội dung bài viết chủ yếu giới thiệu về một số mô hình kiến trúc ứng dụng 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ó tầm nhìn tổng quát, up-to-date cùng là roadmap để bắt đầu hành trình đoạt được (đào sâu) thế giới của những bạn dạng thiết kế với phương châm là phần đa kỹ sư và bản vẽ xây dựng sư phần mềm đam mê cùng với nghề.