Layered Architecture - Software Architecture Pattern
•Télécharger en tant que PPTX, PDF•
5 j'aime•4,747 vues
The most common architecture pattern is the layered architecture pattern, otherwise known as the n-tier architecture pattern. This pattern is the de facto standard for most applications and therefore is widely known by most architects, designers, and developers. The layered architecture pattern closely matches the traditional IT communication and organizational structures found in most companies, making it a natural choice for most business application development efforts.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Layered Architecture - Software Architecture Pattern
Similaire à Layered Architecture - Software Architecture Pattern (20)
Dernier
Dernier (20)
Layered Architecture - Software Architecture Pattern
- 1. Layered Software Architecture 23th May 2018 Thang Nguyen – Chief Technology Officer
- 2. 2 Content 1 Logical Layer Architecture 2 Physical Tier Architecture 3 Comparative 4 Summary 5 Questions
- 6. 6 1990s
- 8. 8 Presentation Layer • Also known as Frontend Layer, User Interface Layer • Responsible for creating and displaying the user interface and handling user interaction • Data shown is fetched from the Domain Layer
- 9. 9 Service Layer • Also known as Web Service Layer • Responsible for exposing a web service, api and returning the method result as XML, JSON, Binary data… • Data returned is retrieved from the Domain Layer
- 10. 10 DomainLayer • Also known as Business Layer • Responsible for all the business logic in the application • Consists of a Domain Model and Domain Service
- 11. 11 DomainModel • Also known as Business Model, Business Objects, Entities… • Responsible for having a model that reflects how the business stakeholders look at the world • Consists of entities with relationships and behavior • Similar to a database model but a domain model is richer
- 12. 12 DomainService • Also known as Business Service, Business Manager… • Business Logic that does not belong within an entity
- 13. 13 Infrastructure Layer • Also known as Data Access Layer, Repository Layer… • Responsible for querying a database, calling a web service, api, sending email, sms …
- 14. 14 Sample • We want to create a task management application with employees and related tasks. A task consist of an id, a task name, a deadline, a finished time. An employee can be assigned many tasks and we want to check task progress completed or miss deadline. • Technology: .NET, ASP.NET MVC
- 20. 20 Sample Show result to the user
- 21. 21 Whyshould youhavemanylayers • Independence • More secure • Reusability • Reusing components easily • Increase flexibility, maintainability, and scalability
- 22. 22 Layer architecture disadvantages • Sometimes difficult to cleanly assign functionality to the “right” layer • Can’t be used for simple application because it adds complexity
- 24. 24 Architecture components • Architecture components of any system is “software” and “hardware” • Software is programs and other operating information used by computer • Hardware is the machines, wiring, and other physical components of a computer or other electronic system.
- 26. 26 2 –Tier windowsclient architecture
- 27. 27 3 –Tier windowsclient architecture
- 28. 28 3 –Tier web architecture
- 30. 30 Whyhavemanytiers • Reuse logic across applications • Improve security, e.g. restrict database access for the client by going through a service • Improved performance, the performance critical tiers can be scaled across multiple servers
- 32. 32 Summary • Logical Layers – How you logically divide the code in application – Three layers architecture is most common • Presentation Layer • Domain Layer with a Domain Model and Domain Service • Infrastructure Layer for communicating with data source • Physical Tiers – How you divide the application into many sub-applications
Notes de l'éditeur
- Những application lúc đó (hầu như) hoàn toàn khác với ngày nay. Chẳng có GUI (cái chỉ mới xuất hiện vào những năm đầu thập nên 90), tất cả application được sử dụng thông qua CLI (Command-line interface) dưới dạng cửa sổ console với nhiệ vụ đơn giản là nhận input (bàn phím) từ người dùng và xuất ngược trở ra màn hình. Cũng chẳng có khái niệm Client-Server, tất cả được đóng gói thành một bản cài đặt trên từng máy trạm.
- Giai đoạn này đã bắt đầu xuất hiện các ứng dụng dành cho doanh nghiệp (enterprise) với lượng người sử dụng dùng máy tính cá nhân (desktop computer) để truy cập vào ứng dụng thông qua network. User Interface (Presentation): là những chương trình chạy trên desktop / CLI hoặc các web page. Các chương trình client lúc này thường là các rich client (nơi luồng công việc và kiểm tra input đầu vào đặt ở client) Business Logic (Domain): là nơi đặt các logic về nghiệp vụ chính của hệ thống, layer này sẽ tiếp nhận các request từ phía Client, xử lý và lưu trữ data thông qua Data source layer. Data source: nhiệm vụ chính của layer này là thực thi các tác vụ lưu trữ dữ liệu và liên lạc với các applications khác (được request từ business logic layer).
- Đây là giai đoạn thế giới công nghệ có những chuyển biến mạnh mẽ. từ những năm 95 đến 2005, thế giới bắt đầu dịch chuyển lên “mây”. Số lượng người dùng tăng lên, độ phức tạp về ứng dụng tăng lên, vấn đề về cơ sở hạ tầng cũng ngày càng phức tạp. Từ đó dẫn đến việc cải tiến các mô hình kiến trúc sao cho phù hợp với nhu cầu, kiến trúc phân lớp vào thời điểm này được biến đổi như sau: Web browser: làm nhiệm vụ render và gửi / nhận request tới server. Application server: chứa presentation layer, the application layer, the domain layer, và the persistence layer. Database server: được tối ưu cho mục đích lưu trữ dữ liệu
- Trong các hệ thống hướng đối tượng, UI, Database và các dạng mã khác thường được viết trực tiếp vào trong logic nghiệp vụ. Và theo chiều ngược lại, mã nghiệp vụ lâu lâu lại được nhúng vào trong UI, DB code. Không có sự phân cấp rõ ràng dẫn đến sự phức tạp trong tổ chức, quá nhiều phụ thuộc lẫn nhau giữa các mã nguồn. Sở dĩ điều này diễn ra là vì lập trình nó rất dễ và nhanh.. nhưng chỉ là lúc mới bắt đầu. Khi các đoạn mã liên quan đến nghiệp vụ được dàn trải ở khắp nơi, điều này sẽ trở nên rất phức tạp và rất khó để đọc được nghiệp vụ. Thay đổi trên giao diện người dùng cũng có thể làm thay đổi business logic. Để thay đổi business logic, chúng ta phải đi ngược lên các mã UI, cơ sở dhiểu ữ liệu hoặc các phần tử của chương trình khác để xem những chỗ cần phải thay đổi theo. Điều này không cần nói cũng đủ hiểu nó gây ra khó khăn như thế nào. Trong kiến trúc phân lớp, các layer có thể được design theo hướng nghiêm ngặt, một layer chỉ có hiểu biết và sử dụng layer ngay bên dưới nó, hoặc theo hướng linh hoạt hơn, nghĩa là một layer có thể sử dụng tất cả các layer ở dưới nó. Cả Martin Fowler và tôi đều tán đồng cách thứ 2 để tạo nên sự linh hoạt, tránh phải tạo ra các proxy method (hoặc thậm chí là proxy class) trong các layer trung gian chỉ để truyền tải thông điệp từ lớp bên trên nó xuống lớp phía dưới nó. Việc sử dụng các layer trung gian như vậy được coi là 1 anti-pattern với tên gọi Lasagna Architecture. Đôi khi các layer được thiết kế sao cho domain layer hoàn toàn không muốn presentation layer biết đến data source layer. Tuy nhiên, và thường xuyên, presentation layer nên truy cập trực tiếp đến data source layer. Mặc dù điều này không tinh khiết, nhưng nó có xu hướng hoạt động tốt hơn trong thực tế.
- User Interface (Presentation): là những chương trình chạy trên desktop / CLI hoặc các web page. Các chương trình client lúc này thường là các rich client (nơi luồng công việc và kiểm tra input đầu vào đặt ở client)
- Layer này chứa các logic liên quan đến nghiệp vụ của ứng dụng, các Entities, Events, và bất cứ object nào handle logic nghiệp vụ. Rõ ràng, nó giống như Entiy trong EBI Architecture; là trái tim của cả hệ thống.
- Domain model nên contains cả Behavior, hiểu Behaviors ở đây là business rules chứ không phải là business process
- Một application service là một service cung cấp các hoạt động không liên quan đến infrastructure (cơ sở hạ tầng của phần mềm), nó sẽ không liên quan đến việc thảo luận về các miền model bên ngoài phần mềm, tức là trong môi trường tự nhiên của nó. Domain Services Domain Services là kịch bản cho một use-case có liên quan đến nhiều đối tượng. Forcing logic này vào một object là sự không khéo léo, vì các use-cases thường liên quan đến các quy tắc, trách hiệm bên ngoài và không phải là của một đối tượng duy nhất. Một infrastructure service đóng gói các truy cập vào một hệ thống bên ngoài. Các infrastructure services thường được sử dụng bới application và domain service. Như là gửi mail, gọi API từ bên ngoài ....
- Đóng vai trò cung cấp thư viện ( supporting libraries )cho các tầng khác. Nó cung cấp cơ chế giao tiếp ( communication ) giữa các Layer với nhau, cũng như cung cấp các chức năng khác như lưu trữ ( persistence ) các Business Object của tầng Domain. Theo mình thì 3 tầng phía trên là khá dễ hiểu vì nó khá tương đồng với mô hình 3 lớp truyền thống, chỉ có tầng Infrastructure là dễ gây confused nhất cho mọi người. Lý do không phải vì sự phức tạp của nó mà do cách dùng từ của thằng cha Eric Evans làm cho người ta dễ hiểu nhầm. Một trong những lý do làm mình ghét mấy thằng Tây viết sách ở trên là vì ngoài việc viết dài vô bổ còn một lý do khác nữa là việc sính dùng từ cũ theo nghĩa mới một cách tùy tiện. Trong ngành IT có một tình trạng hết sức khó chịu đó là việc không có sự chuẩn hóa khái niệm một cách rõ ràng nên cùng một từ thôi nhưng ở nơi này nơi kia được các ông khác nhau sử dụng với nghĩa khác nhau vì ông nào cũng không muốn” tạo dấu ấn riêng” ta đây cũng đều là anh hùng anh bá cả nên cứ phải chơi những thứ mới lạ nó mới độc đáo, chẳng hạn như ông java thì dùng package còn ông .Net thì dùng namespace, 2 cái này về bản chất chẳng khác mẹ gì nhau ? Chẳng qua vì các bố muốn tỏ ra khác biệt không muốn lặp lại của thằng khác nên “sáng tạo” ra khái niệm mới, chỉ khổ anh em nào lúc mới bắt gặp mấy “ từ mới” lại tốn thời gian để tìm hiểu xem cái thằng What The Fuck này nó là cái gì. Chúng ta có thể hiểu cho đơn giản là phần Infrastructure chính là phần các phần cross-cutting concern trong mô hình 3 layer cũ như logging, security, ultility etc… cộng thêm với phần data persistence vốn dĩ thuộc về tầng Data Access Layer cũ nhưng được tách biệt hoàn toàn ra khỏi phần Business Logic để tăng tính stable cho phần Domain và nó sẽ độc lập hơn với Datasource ( chẳng hạn khi chúng ta thay đổi định lưu trữ như từ database sang file hay ngược lại thì phần Domain cũng sẽ không phải thay đổi ). Theo mình nghĩ thì sở dĩ phần này được gọi Infrastructure vì khi tư duy rằng Domain là trái tim của ứng dụng, cần phải focus vào logic của nghiệp vụ thì các công việc khác không được xem là quan trọng sẽ xếp vào công việc điếu đóm bếp núc nên nó sẽ được gọi là Infrastructure code.
- Independence Các components khác nhau trong 1 ứng dụng có thể độc lập triển khai, độc lập duy trì, độc lập cập nhật trong các khung thời gian khác nhau Các thành viên trong team có thể làm việc 1 cách song song trên các phần khác nhau trong ứng dụng với ít sự phụ thuộc nhất Hỗ trợ unit test từng thành phần More secure Mỗi lớp có thể che dấu các nội dung đối với các lớp khác Reusability Mỗi lớp, lớp trên phụ thuộc vào lớp ngay dưới nó, tạo khả năng dễ dàng sử dụng lại, dễ dàng thay thế, thay đổi Reusing components easily Khi cần thay đổi giao diện hiển thị việc thay đổi UI rất nhanh gọn, vì các components như nghiệp vụ, truy xuất đã được xử lý xong
- Phần cứng là máy móc, hệ thống dây điện và các thành phần vật lý khác của máy tính hoặc hệ thống điện tử khác.
- Sử dụng lại logic trên các ứng dụng Cải thiện bảo mật, ví dụ: hạn chế quyền truy cập cơ sở dữ liệu cho máy khách bằng cách thực hiện một dịch vụ Hiệu suất được cải thiện, các mức quan trọng hiệu suất có thể được chia tỷ lệ trên nhiều máy chủ