Software Architecture Patterns

Transcript

1. Software Architecture Patterns Ulugbek Miniyarov Chief Software Architect @ ENUYGUN
2. Purpose of using Patterns - Proven layout in different business logic - Ease of use among multiple developers - Keep things in order
3. Agenda - Service-Oriented Architecture - Domain Driven Development - Command Query Responsibility Segregation - Event Source
4. Service-Oriented Architecture - Separation of Service Interface from underlying implementation of Business Logic (Loose Coupling) - Promotes service reuse through Discoverable and Self-describing services - Services are coarse-grained, composable and rely on standards based infrastructure (RESTful, Web Service, WebRPC, XML PRC, gRPC)
5. Service-Oriented Architecture Pros: - Easily reuse codes and recompose services - Easy to start for new developers - Easy for PMs to manage Cons: - Hard to deploy dependent services - Can be messy with lots of services - Service discoverability and meshing can be painful
6. Domain-Driven Development (DDD) Domain-Driven Design, or DDD, is an approach for building high-quality software that meets core business objectives. It emphasizes collaboration among domain experts, developers, UX designers and other disciplines to create a domain model that reflects the needs of the business. DDD Concepts: - Ubiquitous Language (essential for Domain Experts, Developers, UX Designers, Testers and others) - Domain Model (essential for Domain Experts, Developers, UX Designers, Testers and others) - Bounded Context (For developers) - Command-Query Separation (For developers) - Layered Architecture (For developers) - Domain Layer (For developers)
7. DDD - Ubiquitous Language - Developer are developers -> always thinks in terms of codes, classes, methods - Domain experts -> knows how business logic works - To overcome this difference in communication we build common language on domain called: Ubiquitous Language
11. DDD - Domain Model - Entity - Value Objects - Entities and Value Object Relations
12. DDD - Bounded Context - Large projects can contain lots of concepts: Account, Order, Order Execution, Payment - Large domains can be divided for simpler management: Domain models are bounded within contexts - No magical way to divide, group together models that are related
13. DDD - Command Query Separation - Simplify Designs - Improve Performance - Eventually Consistent - Details in Command-Query Responsibility Segregation
14. DDD - Layered Architecture - Separation of Concerns - Easer to Maintain - Multiple teams can work altogether
15. DDD - Domain Layer - Entities - Value Objects - Domain Services - Domain Events - Aggregates
16. DDD - Summary • Use Domain-Driven Design to collaborate among all project disciplines and clearly understand the business requirements. • Establish a Ubiquitous Language to discuss domain related concepts. • Use Bounded Contexts to break down complex domains into manageable parts. • Use Command-Query Separation to simplify your designs and improve performance. • Implement a Layered Architecture to focus on different aspects of the application.
17. Command Query Responsibility Segregation Command Query Responsibility Segregation (CQRS), comes from CQS (Command Query Separation) introduced by Bertrand Meyer in Object Oriented Software Construction. - Every method should be a Command or Query - Command: States a change - Query: Returns a value
18. CQRS
19. Event Source - Easy to understand events in a domain - Event history is kept immutable - Can replay events to mimic user actions
20. CQRS + ES Pros: - Work with large teams - Simpler business logic - Scalable thanks to eventually consistent architecture Cons: - Overkill CRUD operations - More moving parts - Event sources can be hard for analyts and BI unit
21. CAP Theorem in CQRS Computer scientist Eric Brewer, states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency: Every read receives the most recent write or an error Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write Partition Tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
22. PACELC (extension of CAP) In theoretical computer science, the PACELC theorem is an extension to the CAP theorem. It states that in case of network partitioning (P) in a distributed computer system, one has to choose between availability (A) and consistency (C) (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and consistency (C).
23. Eventually Consistent vs Strongly Consistent Eventually Consistent: offers low latency but may reply to read requests with stale data since all nodes of the database may not have the updated data. Strongly Consistent: offers up-to-date data but at the cost of high latency.
24. Thank you. References: - Mastering PHP Design Patterns Book - ArchFirst (https://archfirst.org/) - CQRS (https://en.wikipedia.org/wiki/Command%E2%80%93query_separation) - CAP Theorem (https://en.wikipedia.org/wiki/CAP_theorem) - PACELC Theorem (https://en.wikipedia.org/wiki/PACELC_theorem)