{"id":34037,"date":"2026-06-08T12:05:28","date_gmt":"2026-06-08T10:05:28","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=34037"},"modified":"2026-06-08T21:43:15","modified_gmt":"2026-06-08T19:43:15","slug":"architecture-beyond-layers-tsarch-for-ai-agents","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/architecture-beyond-layers-tsarch-for-ai-agents\/","title":{"rendered":"Architecture Beyond Layers: tsarch for AI Coding Agents"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 2 of 2 in the series “AI-assisted Angular Architecture”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. AI-Assisted Coding: Architecture as an Executable Contract<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Architecture Beyond Layers: tsarch for AI Coding Agents<\/span><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    In the first part of this series we built the big guardrail: architecture rules get documented, brought into the coding agent's context through Rules and Skills, checked with Sheriff, and fed back as deterministic feedback via Stop hooks.<\/p>\n

    That closes the feedback loop for domain and layer boundaries. With Feature Slicing, however, additional rules arise within<\/em> a feature \u2013 for example between Smart and Dumb Components, Stores, and services for data access.<\/p>\n

    This is exactly where this second part comes in. We extend the setup with tsarch<\/strong>, a tool for TypeScript projects inspired by the well-known ArchUnit<\/strong> library. With it, naming and access conventions become executable architecture rules \u2013 checked as a unit test and wired into the same agent feedback loop that already carried Sheriff in the first part.<\/p>\n

    Where layers reach their limits, naming conventions take over: tsarch checks them deterministically and turns an architecture violation into machine feedback that the coding agent picks up.<\/em><\/p>\n

    \ud83d\udcc2 Source Code<\/a> (Branch: ai-arc<\/code>)<\/p>\n

    Architecture Rules via Building Blocks in Addition to Layers<\/h2>\n

    In the first part we used Sheriff to channel the communication between modules: domains represent functional boundaries, layers technical ones. However, not all technical constraints can be expressed well through layers \u2013 especially not when, with Feature Slicing, we allow a feature to have its own Dumb Components, data access services, and Stores. These building blocks then sit together in the feature folder rather than separated into their own layers.<\/p>\n

    That is why we additionally constrain things by Building Blocks<\/strong> here. What matters is no longer just which layer a building block sits in, but what kind<\/em> of building block it is \u2013 and which building blocks may access which:<\/p>\n

    \"Building<\/p>\n

    The central rule for our example project is: a Smart Component<\/strong> accesses a Store<\/strong>, and only the Store accesses the Data Access client<\/strong>. Smart Components therefore must not access the client directly, and Stores must not access other Stores.<\/p>\n

    Especially when using lightweight Stores, you often need a Coordinator<\/strong> that stores no data itself but, for a use case, provides the states from different Stores \u2013 possibly from different layers \u2013 and ties them together via computed<\/code> signals. This use-case orchestration is handled by the Coordinator, which from the component's point of view looks like a "real" Store. This way we avoid Store-to-Store dependencies, and thus cycles, without giving up the convenience of a bundled view across multiple Stores.<\/p>\n

    There is one deliberate exception for Dumb Components<\/strong>: they only get access to Stores in the same folder or in child folders. In this case we assume local state management that is a pure implementation detail of the Dumb Component. Apart from that, Dumb Components must not access any of the other building blocks described here.<\/p>\n

    Recognizing Building Blocks via File Suffixes<\/h2>\n

    We recognize the individual building blocks by their file suffixes. This fits well with the current conventions of the Angular team, implemented by the CLI: components, services, and directives no longer get default suffixes. Not because suffixes are bad, but because generic suffixes like Component<\/code> or Service<\/code> offer too little value. The Angular team explicitly emphasized, however, that you can assign your own, semantically stronger suffixes \u2013 and that is exactly what we use here.<\/p>\n

    In our demo project I decided on the following suffixes:<\/p>\n