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

Agent-Friendly Software Architecture

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
Avatar for Henning Schwentner Henning Schwentner
September 17, 2026
180

Agent-Friendly Software Architecture

Avatar for Henning Schwentner

Henning Schwentner

September 17, 2026

Transcript

  1. Give the Agent Context what the agent sees North Avenue

    Ba ke r La ne Main Street Market Square Harbour Road Mill Way Quayside City Park hschwentner.io
  2. Good context is not “as much context as possible,” but

    “the right slice of context” hschwentner.io
  3. Architecture Term: Module accessible A part of a software that

    hides its implementation/a decision behind an interface. interface Study it without reading the rest. implementation e.g. a method, a class, a bounded context hschwentner.io hidden
  4. Examples for Modules class aggregate interface: public methods implementation: fields,

    private methods Java module method function interface: signature implementation: body bounded context interface: in- and outgoing events implementation: inner stuff hschwentner.io
  5. Examples for NonModules function method namespace no information hiding interface:

    signature implementation: body bounded context interface: in- and outgoing events implementation: inner stuff hschwentner.io
  6. Separation of Concerns “…study in depth an aspect in isola,on

    […], all the ?me knowing that one is occupying oneself only with one of the aspects.” Edsger Dijkstra one aspect in isolation 1974 hschwentner.io
  7. Loose Coupling/ High Cohesion 1979 knowledge needed to work on

    the left Ed Larry module hschwentner.io Yourdon Constantine !
  8. Cognitive Load 1956 everything else in the repo 40 files

    of context the actual task 1988 hschwentner.io George A. Miller John Sweller
  9. Hypothesis 1: To keep the “cognitive load” of an agent

    right, keep the context window right
  10. Hypothesis 2: architecture that has always made a codebase legible

    to humans == architecture that makes it legible to agents
  11. Fundamental Theorem of Software Engineering “We can solve any problem

    by introducing an extra level of indirection” “…except for the problem of too many levels of indirection” $ David Wheeler hschwentner.io
  12. Patterns Ralph Johnson Erich Gamma Richard Helm J o hn

    Vlissides ! " # ! a.k.a.: Gang of Four hschwentner.io
  13. e t The Problem e r c n o Domain

    C bank transaction Infrastructure Oracle DB hschwentner.io BAD!
  14. rt po r te ap ad http://alistair.cockburn.us/Hexagonal%2Barchitecture adapter hschwentner.io Foto:

    Dennis Hamilton/flickr/CC BY 2.0 Hexagonal Architecture Alistair Cockburn port
  15. Kinds of Ports - For UI etc. - Methods to

    be called - “from above” - For DB and infrastructure - Interfaces to be implemented - “from below” hschwentner.io
  16. Domain 1 p The Solution Ste Domain bank transaction bank

    transaction port Infrastructure Infrastructure adapter Oracle DB Oracle DB hschwentner.io
  17. services re domain model ! ices rv se cation i

    l p ap domain tu U I Onion Architecture c u r t s a r inf “application core” hschwentner.io
  18. The 4 Tenets •The application is built around an independent

    object model •Inner layers define interfaces. Outer layers implement interfaces •Direction of coupling is toward the center •All application core code can be compiled and run separate from infrastructure ! hschwentner.io Jeffrey Palermo !
  19. Designed for Testability “All application code can be compiled, run,

    and tested separate from infrastructure” Easy unit tests Plays well with TDD hschwentner.io !
  20. control eb gat e pr es en te rs U

    I use cases entities ys DB w rs le de vi c es Clean Architecture wa interactor = use case object Robert C. Martin “Uncle Bob”
  21. Structure alone gets an LLM surprisingly far. Names help most

    where the domain isn’t a textbook one.
  22. To build software, "% ! $ # tech people have

    to understand business people
  23. To build software, % " & & & ! $

    # tech people and agents have to understand business people
  24. Ubiquitous Language Teach the agent the language of the domain

    à Let the agent understand the domain Eric Evans hschwentner.io !
  25. Architecture Hamburgerel UI lay v e l er Application Domain

    Infrastructure hschwentner.io $ Henning Schwentner
  26. Architecture Hamburgerock REST framework widget library view controller transaction handling

    model use case repository interface service programming language domain library entity domain event value object ORM file system access data model repository implementation hschwentner.io l b g n i d l i l e bu lev
  27. ARCHITECTURERULES.md # Architecture Rules How this system is built. Not

    a survey of what exists. Prescription, not description à The current architecture lives in ARCHITECTURE.md ## Style - Hexagonal, not layered. Adapters depend inward; the domain depends on nothing. [DependencyRulesTest] - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; modules talk through published interfaces, never through each other's tables. [ModuleApiTest] Style, not domain. ## Choices, where others are also reasonable - Ports live beside the domain, not in their own package. [PortLocationTest] - Mapping is hand-written. No MapStruct. [no test] - Persistence returns domain types, not entities. [no test] The contexts and their language live in CONTEXT-MAP.md. ## Enforcement Every rule here is an ArchUnit test. Rules marked [no test] are not yet enforced: if you touch code they govern, write the test first. Make it fail, then fix the code. Where a test and this file disagree, the file wins — fix the test. Where code breaks a rule and the suite stays green, the test is missing. All can be referenced from AGENTS.md. ## Known deviations - sales reads risk tables directly (owner: HS, #412). Do not add to this. New code goes through the port. hschwentner.io
  28. ARCHITECTURERULES.md # Architecture Rules Style, not domain. The contexts and

    their How this system should be built. language live in CONTEXT## Style MAP.md. - Hexagonal, not layered. Adapters depend inward; the # Architecture Rules How this system is built. Not a survey of what exists. Not a survey of what exists. domain depends on nothing. [DependencyRulesTest] - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; modules talk through published interfaces, never through each other's tables. [ModuleApiTest] Both referenced from AGENTS.md. ## Choices, where others are also reasonable - Ports live beside the domain, not in their own package. [PortLocationTest] - Mapping is hand-written. No MapStruct. [no test] - Persistence returns domain types, not entities. [no test] ## Enforcement Every rule here is an ArchUnit test. Rules marked [no test] are not yet enforced: if you touch code they govern, write the test first. Make it fail, then fix the code. Where a test and this file disagree, the file wins — fix the test. Where code breaks a rule and the suite stays green, the test is missing. ## Known deviations - sales reads risk tables directly (owner: HS, #412). Do not add to this. New code goes through the port. hschwentner.io
  29. ARCHITECTURERULES.md # Architecture Rules How this system is built. Not

    a survey of what exists. ## Style Style, not domain. The contexts and their language live in CONTEXTdepend inward; the domain depends MAP.md. ## Style - Hexagonal, not layered. Adapters depend inward; the domain depends on nothing. [DependencyRulesTest] - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; modules talk through published interfaces, never through each other's tables. [ModuleApiTest] - Hexagonal, not layered. Adapters on nothing. ## Choices, where others are also reasonable - Ports live beside the domain, not in their own package. [PortLocationTest] - Mapping is hand-written. No MapStruct. [no test] - Persistence returns domain types, not entities. [no test] [DependencyRulesTest] Both referenced from AGENTS.md. - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; ## Enforcement Every rule here is an ArchUnit test. Rules marked [no test] are not yet enforced: if you touch code they govern, write the test first. Make it fail, then fix the code. Where a test and this file disagree, the file wins — fix the test. Where code breaks a rule and the suite stays green, the test is missing. modules talk through published interfaces. [ModuleApiTest] ## Known deviations - sales reads risk tables directly (owner: HS, #412). Do not add to this. New code goes through the port. hschwentner.io
  30. ARCHITECTURERULES.md # Architecture Rules How this system is built. Not

    a survey of what exists. ## Choices, where others are also reasonable ## Style - Hexagonal, not layered. Adapters depend inward; the domain depends on nothing. [DependencyRulesTest] - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; modules talk through published interfaces, never through each other's tables. [ModuleApiTest] Style, not domain. The contexts and their language live in CONTEXT- Ports live beside the domain.MAP.md. ## Choices, where others are also reasonable - Ports live beside the domain, not in their own package. [PortLocationTest] - Mapping is hand-written. No MapStruct. [no test] - Persistence returns domain types, not entities. [no test] [PortLocationTest] Both referenced from - Mapping is hand-written. No MapStruct. AGENTS.md. [no test] ## Enforcement Every rule here is an ArchUnit test. Rules marked [no test] are not yet enforced: if you touch code they govern, write the test first. Make it fail, then fix the code. Where a test and this file disagree, the file wins — fix the test. Where code breaks a rule and the suite stays green, the test is missing. - Persistence returns domain types. [no test] ## Known deviations - sales reads risk tables directly (owner: HS, #412). Do not add to this. New code goes through the port. What the model cannot guess. hschwentner.io
  31. ARCHITECTURERULES.md # Architecture Rules How this system is built. Not

    a survey of what exists. ## Style - Hexagonal, not layered. Adapters depend inward; the domain depends on nothing. [DependencyRulesTest] - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; modules talk through published interfaces, never through each other's tables. [ModuleApiTest] Style, not domain. ## Enforcement The contexts and their language live in CONTEXT- Ports live beside the domain, not in their own Rules marked [no test] are not yet MAP.md. package. [PortLocationTest] Every rule here is an ArchUnit test. ## Choices, where others are also reasonable - Mapping is hand-written. No MapStruct. [no test] - Persistence returns domain types, not entities. [no test] enforced: if you touch code they Both referenced from govern, write the test first. ## Enforcement Every rule here is an ArchUnit test. Rules marked [no test] are not yet enforced: if you touch code they govern, write the test first. Make it fail, then fix the code. Where a test and this file disagree, the file wins — fix the test. Where code breaks a rule and the suite stays green, the test is missing. AGENTS.md. Make it fail, then fix the code. Where a test and this file disagree, ## Known deviations - sales reads risk tables directly (owner: HS, #412). Do not add to this. New code goes through the port. the file wins - fix the test. Suite green on broken rule? Test missing. hschwentner.io
  32. ARCHITECTURERULES.md # Architecture Rules How this system is built. Not

    a survey of what exists. ## Style - Hexagonal, not layered. Adapters depend inward; the domain depends on nothing. [DependencyRulesTest] - Domain imports no framework types. [DomainPurityTest] - One module per bounded context; modules talk through published interfaces, never through each other's tables. [ModuleApiTest] ## Known deviations ## Choices, where others are also reasonable - Ports live beside the domain, not in their own package. [PortLocationTest] - Mapping is hand-written. No MapStruct. [no test] - Persistence returns domain types, not entities. [no test] - sales reads risk tables directly. owner: HS, issue #412 ## Enforcement Every rule here is an ArchUnit test. Rules marked [no test] are not yet enforced: if you touch code they govern, write the test first. Make it fail, then fix the code. Where a test and this file disagree, the file wins — fix the test. Where code breaks a rule and the suite stays green, the test is missing. Do not add to this. New code goes through ## Known deviations - sales reads risk tables directly (owner: HS, #412). Do not add to this. New code goes through the port. the port. Honest about what is already broken. hschwentner.io
  33. Bibliography Cockburn, Alistair. “Hexagonal Architecture.” January 4, 2005. https://alistair.cockburn.us/hexagonal-architecture/. Dijkstra,

    Edsger. “Go To Statement Considered Harmful.” Communications of the ACM 11, no. 3 (March 1968): 147–48. Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley, 2004. Lilienthal, Carola and Henning Schwentner. Domain-Driven Transformation: Modernize Legacy Software and Mitigate Risk. Santa Rosa, CA: O’Reilly, 2026. Parnas, David L. “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM 15, no. 12 (December 1972): 1053–58. Yourdon, Edward and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. New York: Yourdon Press, 1979. hschwentner.io
  34. Henning Schwentner   ✉ Kolleg:in ges ucht (Deutschlan dweit)

    https://hschwentner.io in/henningschwentner [email protected] en v i r D ain-mation m o D sfor Tran Legac rnize Mode nd ems a y Syst k te Ris Mitiga al & ienth ner t la Lil Caro Schwen thers g a in Fe h ae l H en n ic by M word Fore