Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Thinking Architecturally

Avatar for John John
March 21, 2026

Thinking Architecturally

A talk all about thinking about architecture in terms of dependencies, and how these dependencies connect, but also how the size and complexity of the codebase impacts architecture.

Avatar for John

John

March 21, 2026
Tweet

More Decks by John

Other Decks in Programming

Transcript

  1. What is Object-oriented programming? ”Object-oriented programming (OOP) is a programming

    paradigm based on the concept of objects.[1] Objects can contain data (called fields,attributes or properties) and have actions they can perform (called procedures or methods and implemented in code)” Source: https://en.wikipedia.org/wiki/Object-oriented_programming
  2. What is Object-oriented programming? ”Object-oriented programming (OOP) is a programming

    paradigm based on the concept of objects.[1] Objects can contain data (called fields,attributes or properties) and have actions they can perform (called procedures or methods and implemented in code)” Source: https://en.wikipedia.org/wiki/Object-oriented_programming
  3. What is Object-oriented programming? ”Object-oriented programming (OOP) is a programming

    paradigm based on the concept of objects.[1] Objects can contain data (called fields,attributes or properties) and have actions they can perform (called procedures or methods and implemented in code)” Source: https://en.wikipedia.org/wiki/Object-oriented_programming Named map/struct Function
  4. Unit test • No mocks • No fakes • No

    TestContainers • No Spring (DI Framework) test setup
  5. Summary • Allow architectures to change as the system evolves.

    • Try to determine whether systems are complicated due to architectural constraints or because they’re doing something complex (The former is more common). • More advanced architectures will feel more complex because they are, but they can handle more complexity. • When writing APIs, start by being specific and only become generic when needed. • Keep in mind what the product is. Everything else should support the product – API design, architecture, etc.