Design Concepts

Domain Driven Design

A concept introduced by Eric Evans in 2004 in his book Domain-Driven Design: Tackling Complexity in Heart of Software.

• The word Domain used in context of software development refers to business. The subject area on which the application that is being developed applies is called the Domain

• To prevent two domains to pollute each other, you have to create a boundary between them. Each domain has its ubiquitous language and its domain model. An anti-corruption layer translates between the two domain models.

• When we are developing software our focus should not be primarily on technology, rather it should be primarily on business

• Talks about two kinds of design tools
  • Strategic design tools
    • help us to solve problems that are related to software modeling
    • Model – It acts as a core logic and describes selected aspects of domain. it is used to solve problems related to that business.
    • Ubiquitous Language – A language shared by the development team and the domain experts. Consider it like using common verbs and nouns for classes, methods, services, and objects while talking with domain experts and team members. The language has to be used not only in the domain model, but also in the code of the application
    • Bounded Context – To deal with a large model you can divide the model into different zones which we call a “Bounded Context”
  • Tactical design tools
    • talks about implementation details. It generally takes care of components inside a bounded context
    • Entity –  is a class that has some properties. The instance of these classes has a global identity and keeps same identity throughout lifespan
    • Value Objects – These are immutable, light-weight objects that don’t have any identity. Value objects reduce complexity by performing complex calculations, isolating heavy computational logic from entities
    • Value Objects have no identity, while an Entity does. Entities exist on their own, Value Objects do not live on their own and belong to some Entity
    • Eg – “User” is an Entity and his “Address” is a value object. Address can change, but user is fixed. 
    • Aggregate – An aggregate is a collection of entities and values which come under a single transaction boundary. User + Address is called an aggregate.
    • Factories and Repositories – Factories help in managing beginning of lifecycle of aggregates whereas Repositories help in managing middle and end of lifecycle of an aggregate

Event/Message Driven Architecture

(Link)

 An architectural paradigm where behavior is composed by reacting to events / messages. Allows you to create a systems architecture in which the flow of information is determined by messages. AKA message-driven architecture or stream processing architecture

A message bus serves as the event delivery mechanism. Services listen on Topics in the message queue, consume new messages, and then react to them

Events can be grouped into logical collections of events called topics. Topics are partitioned for parallel processing. We can think of a partitioned topic as a queue. Events can be discrete or series.

Event Bus Topologies

• Mediator topology
  • The mediator topology pattern is used to design systems/processes that will need some level of coordination/orchestration in order to process the event. This topology uses a single event queue and an event mediator to route events to the relevant event processors
  • 
• Broker Topology
  • The event broker topology pattern is used in scenarios where the event flow is relatively simple in nature and does not require any central event orchestration. In a broker topology, the event messages created by event producers enter an event broker. The event processors are responsible for picking up events from an event broker.
  • 

SOLID Design Principles

 popular sets of design principles in object-oriented software development.

• Single Responsibility Principle (SRP)
  • “a class should have only one reason to change” which means every class should have a single responsibility or single job or single purpose
• Open/Closed Principle
  • “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”
• Liskov’s Substitution Principle (LSP)
  • Derived or child classes must be substitutable for their base or parent classes
• Interface Segregation Principle (ISP)
  • principle that applies to Interfaces instead of classes in SOLID and it is similar to the single responsibility principle
  • “do not force any client to implement an interface which is irrelevant to them”
• Dependency Inversion Principle (DIP)
  • classes should depend upon interfaces or abstract classes instead of concrete classes and functions.

Link , Link

12 Factor App

The 12 Factor App is a set of principles that describes a way of making software that, when followed, enables companies to create code that can be released reliably, scaled quickly, and maintained in a consistent and predictable manner

• Codebase (One codebase tracked in revision control, many deploys)
• Dependencies (Explicitly declare and isolate the dependencies)
  • managing the dependencies externally using dependency management tools instead of adding them to your codebase. Eg Maven
• Config (Store configurations in an environment)
  • not hardcode any configuration values as constants in the codebase
• Backing Services (treat backing resources as attached resources)
  • automatically swap the application (DB, Message Broker etc) from one provider to another without making any modifications to the code base, but with config
• Build, release, and Run (Strictly separate build and run stages)
• Processes (execute the app as one or more stateless processes)
  • application should store the state in the database instead of in memory of the process
  • avoid using sticky sessions
• Port Binding (Export services via port binding)
  • completely self-contained and doesn’t rely on runtime injection of a webserver into the execution environment to create a web-facing service. Eg Spring boot by default comes with embedded tomcat
• Concurrency (Scale out via the process model)
  • advocate to opt-in for horizontal scaling instead of vertical scaling
• Disposability (maximize the robustness with fast startup and graceful shutdown)
  •  When the application is shutting down or starting, an instance should not impact the application state
  • Eg : Storing request, state, or session data in queues or other backing services ensures that a request is handled seamlessly in the event of a container crash
• Dev/prod parity (Keep development, staging, and production as similar as possible)
  • keeping the gap between development and production environment as minimal as possible
• Logs (Treat logs as event streams)
  • separating the log generation and processing the log’s information
  • Eg : Observability can be achieved through using APM tools (ELK, Newrelic, and other tools) or log aggregations tools like Splunk, logs, etc
• Admin processes (Run admin/management tasks as one-off processes)
  • Ensure one-off scripts are automated and maintained in the same repository so that you don’t need to worry about executing them manually before releasing the build

Consistent Hashing

 a strategy for dividing up keys/data between multiple machines

• Conceptually, consistent hashing has a lot in common with hash maps.

  The main difference is that instead of mapping a key to a value, we’ll be mapping a key to the machine responsible for storing the value

• Common hash functions – MD5, SHA1, and SHA256 
• Optimum solution: Assign machines multiple identifies, Hash them, and assign keys to the next machine on the number line (ring)

Link, Link1, Link2 

Rest vs HTTP

Link

Reactive Architecture

Reactive Architecture is nothing more than the combination of reactive programming and software architectures. Also known as reactive systems, the goal is to make the system responsive, resilient, elastic, and message driven.

Reactive Programming is frequently used to build a Reactive System but using Reactive Programming does not mean that a Reactive System will be built unless it has not followed Reactive Principles.