Software Architecture Patterns Ulugbek Miniyarov Chief Software Architect @ ENUYGUN

Purpose of using Patterns - Proven layout in different business logic - Ease of use among multiple developers - Keep things in order

Agenda - Service-Oriented Architecture - Domain Driven Development - Command Query Responsibility Segregation - Event Source

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)

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

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)

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

No content

No content

No content

DDD - Domain Model - Entity - Value Objects - Entities and Value Object Relations

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

DDD - Command Query Separation - Simplify Designs - Improve Performance - Eventually Consistent - Details in Command-Query Responsibility Segregation

DDD - Layered Architecture - Separation of Concerns - Easer to Maintain - Multiple teams can work altogether

DDD - Domain Layer - Entities - Value Objects - Domain Services - Domain Events - Aggregates

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.

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

CQRS

Event Source - Easy to understand events in a domain - Event history is kept immutable - Can replay events to mimic user actions

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

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

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).

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.

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)