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)
- 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
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)
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
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
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.
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
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
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
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).
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.
miniyarov
raygrieselhuber
irinanazarova
brettharned
addyosmani
holman
samlambert
akademiya2063
aleyda
schlessera
bermonpainter
bkeepers
frankvandijk
