Victor Rentea

An architect has no simple, clean decision to take - everything is a trade-off with pros and cons to evaluate within the constraints of the project. But only after a decision is made, the real struggle starts - everyone in the team must learn to apply it in their daily work, and understand the WHY behind it in order to adjust that decision if the problem constraints shift. Join this deep dive into the mainstream backend architecture styles, understand pros and cons of typical design decisions, and learn how to gradually evolve your architecture to support more complexity.

The first day explains the foundational design principles, overview Domain-Driven Design concepts, assembles the classic Layered Architecture and shows what Evolutionary Architecture means in practice. The second day starts with a comparison of classical concentric architectural styles (Hexagonal-, Clean-, Onion-), along with common pragmatic simplifications. However, during more than half of day we study how to slice a monolithic application into modules, to tame the complexity that would otherwise eventually make the code unmaintainable. 

To bring these concepts to life, instructor and participants will refactor 2 simple Java applications, briefly discussing how modern frameworks simplify our work, but keeping our focus on architectural decisions and how they relate with the fundamental design principles and values.

After this workshop you will be able to:

• Develop a firm understanding of the core architectural principles.
• Learn to analyze tradeoffs of design decisions.
• Master the state-of-the-art backend architectural styles.
• Implement architectural changes incrementally, without big rewrites.

This workshop is for you if:

• You are a developer that wants to become an architect 
• You are a technical coach or architect that wants an update on current practices in architectures
• You are looking to debate emerging design practices you observed

Agenda:

• Fundamentals

• • Coupling and Cohesion link
  • SOLID Principles Overview
  • Documenting Architectural Decisions (ADR)

• The Domain Model
  • Ubiquitous Language
  • Enrich Domain Entities with behavior (OOP) 
  • Strategies to maintain domain invariants
  • Exercise: refactor to a Rich Domain Model

• Exposing an API

• • API Design Best Practices
  • Contract- vs Code-first API
  • The Fallacy of Automatic Mappers
  • Task-Based UI
  • Versioning Strategies

• Consuming an API
  • Adapter Pattern and Dependency Inversion Principle
  • Enforcing Boundaries with Architectural Fitness Functions 
  • Exercise: refactor integration logic out of domain
  • Data Persistence – debate: friend or foe?

• Layered Architecture

• • Definition and Flavors
  • Façade Pattern and Separation by Levels of Abstraction Principle
  • Taming Complexity via Application Services (DDD) or Vertical-Slice Architecture (VSA)
  • Exercise: Extract domain logic in Domain Services

• Concentric Architectures
  • Hexagonal Architecture (aka Ports-and-Adapters)
  • Onion Architecture, plus a Pragmatic Variation
  • The 5 Rules of a Clean Architecture
  • Pragmatics: Use-case-optimal Query, ORM on Domain, Self-mapping DTOs, Inline Controllers
  • Exercise: Refactoring to Hexagonal and Onion

• Technical vs Domain Partitioning

• • Definition, Pros/Cons of each
  • Conway’s Law and the Inverse Conway maneuver
  • Architecture and Organization Alignment
  • Team Topologies
  • Identifying and Sizing Components
  • Partitioning Strategies: by data or by capability
  • Exercise: Identifying partitioning

• The Modular Monolith Architecture (aka ‘Modu-lith’)
  • Best way to start a greenfield project (link)
  • Strategies to split a Big Ball of Mud legacy monolith
  • Defining a Module and its API
  • Database Decomposition Stages
  • Break Cyclic Dependencies by clarifying inter-module strategical relationships
  • Exercise: Refactor monolith to functional modules, using Spring Modulith

Wrap-up: Quiz & More Debates

* If you're interested in this program, please contact us at info@itkonekt.com to find out more about availability and prices.