0
0
LLDsystem_design~12 mins

Law of Demeter in LLD - Architecture Diagram

Choose your learning style9 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale
System Overview - Law of Demeter

The Law of Demeter is a design guideline for developing software, especially object-oriented systems. It encourages minimal knowledge sharing between components, promoting loose coupling and easier maintenance.

The key requirement is that each component should only communicate with its immediate friends and not with strangers, reducing dependencies.

Architecture Diagram
User
  |
  v
Client Component
  |
  v
Service Component
  |
  v
Data Component
Components
User
actor
Initiates requests to the system
Client Component
component
Handles user requests and communicates only with its direct collaborators
Service Component
component
Performs business logic and interacts only with its immediate data components
Data Component
component
Manages data storage and retrieval
Request Flow - 6 Hops
User → Client Component
Client Component → Service Component
Service Component → Data Component
Data Component → Service Component
Service Component → Client Component
Client Component → User
Failure Scenario
Component Fails:Service Component
Impact:Client Component cannot get business logic results, causing request failures.
Mitigation:Implement fallback mechanisms or circuit breakers in Client Component to handle service unavailability gracefully.
Architecture Quiz - 3 Questions
Test your understanding
According to the Law of Demeter, which component should the Client Component communicate with directly?
AOnly its immediate collaborators like Service Component
BAny component in the system
CDirectly with Data Component
DWith User and Data Component simultaneously
Design Principle
The Law of Demeter promotes loose coupling by restricting components to communicate only with their immediate collaborators. This reduces dependencies, making the system easier to maintain and evolve.