Skip to content

Architecture Patterns

Glossary

  • Test Driven Development
    • Helps build code that is correct and enables refactoring or adding new features without fear of regression
  • Domain Driven Design
    • Focuses on building a good model of the business domain, without the model being encumbered with infrastructure concerns and don’t become hard to change
    • General idea - The most important thing about software is that it provides a useful model of the problem. If we get that model right, our software delivers value and makes new things possible. If we get the model wrong, it becomes an obstacle to work around.
  • Event Driven Services
    • Loosely coupled microservices integrated via messages (sometimes called reactive microservices) are a well established answer for managing complexity across multiple applications or business domains
  • Encapsulation
    • Simplifying behaviour and hiding data
  • Layered Architecture

    • Divide code into discrete categories or roles and introduce rules about which categories of code can call each other
    • One of the most common patterns for building business software
    graph TD
      p(Presentation Layer) --> b(Business Logic)
      b --> d(Database Layer)
    
    • One of the most common ways that designs go wrong is that business logic becomes spread throughout the layers of the application, making it hard to identify, understand and change
  • Dependency Inversion Principle

    • Formal definition
      • High level modules should not depend on low level modules. Both should depend on abstractions
      • Abstractions should not depend on details. Instead details should depend on abstractions
    • Business logic shouldn’t depend on technical details, instead both should use abstractions
    • Why: So that it’s easier to change them independently. High level modules should be easy to change in response to business needs. Low level modules are harder to change
  • High Level Module
    • Code that your organisation really cares about
    • e.g. for a Bank, their high level modules manage trades and exchanges
    • The functions, classes and packages that deal with real world concepts
  • Low Level Modules
    • Code that your organisation doesn’t care about
    • e.g. code related to file systems, network sockets or protocols (HTTP, AMQP)
  • Repository Pattern
    • Abstraction over the idea of persistent storage
  • Service Layer
    • Clearly define where our use case begins and end
  • Unit of Work Pattern
    • Provides atomic operations
  • Aggregate Pattern
    • Enforce integrity of our data
  • Domain Modelling
    • Domain - the problem you’re trying to solve
    • Model - map of a process or phenomenon that captures a useful property
    • Domain model - the mental map that business owners have of their businesses

Last update: August 11, 2023
Created: June 3, 2023