--- title: "Why are we talking about architecture again?" url: https://daily.dev/posts/why-are-we-talking-about-architecture-again--qeiyintcw source_url: https://itnext.io/why-are-we-talking-about-architecture-again-9810accf3852 type: article source: "ITNEXT" published: 2026-08-20T22:17:45.975Z updated: 2026-08-20T22:51:24.487Z tags: ["webdev", "react", "architecture", "domain-driven-design"] reading_time: 17 upvotes: 19 comments: 3 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why are we talking about architecture again? **[ITNEXT](https://daily.dev/sources/itnext)** · 17 min read · 19 upvotes · 3 comments ## Summary Frontend developers often assume a framework like React, Vue, or Angular automatically solves code organization, but frameworks are UI rendering tools that shouldn't own business logic, routing, or domain rules. Mixing business logic into components leads to tight coupling, circular dependencies, refactoring pain, and slow tests. The piece surveys existing solutions—Feature-Sliced Design and Clean/Hexagonal Architecture—weighing their pros and cons, then proposes a hybrid: Tactical DDD combined with an Nx monorepo. Each business domain is split into contracts, core, ui, and features libraries with strict import boundaries enforced via Nx's module-boundary linter rules and custom generators. A Composition Root with a DI container (InversifyJS) wires dependencies at the app entry point. Benefits claimed include isolated unit testing of business logic, faster incremental builds via Nx caching, protection against framework lock-in, and enabling parallel team work across domains. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What are the drawbacks of Feature-Sliced Design (FSD) for frontend architecture? Feature-Sliced Design still puts the UI front and center, since it doesn't force isolating the application core from the rendering framework, letting developers drag state libraries like Zustand, Vuex, or RxJS directly into slices and lock the domain to the framework. It also restricts same-layer slices from importing each other, forcing cross-domain logic up into bloated widgets or pages layers. _Teams weighing FSD against other structures can compare tradeoffs like these through daily.dev before committing to a frontend architecture._ ### How do you structure a business domain using Tactical DDD in an Nx monorepo for a frontend app? Each business domain splits into four Nx libraries: contracts (pure TypeScript types with zero dependencies), core (pure business logic divided into domain, application, and infrastructure sublayers), ui (dumb presentational components), and features (orchestrator components connecting core to ui). Only contracts and core are mandatory; a domain like permissions can skip ui and features entirely if it has no interface. _Frontend engineers designing scalable domain boundaries can track approaches like this Tactical DDD plus Nx setup via daily.dev._ ### How can you prevent developers from importing UI components into business logic in a monorepo? Use the Nx ESLint rule @nx/enforce-module-boundaries to tag libraries with scope tags (domain:auth, domain:payments) and layer tags (type:contracts, type:core, type:ui, type:features), then define a permission matrix so type:core can only import type:contracts and shared libraries. Violations get flagged by the linter and block the CI pipeline's pull request. _Developers enforcing architectural boundaries in a monorepo can find practical linter setups like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@taiwofrancis** · 0 upvotes > The older I get, the more I appreciate boring architecture. **@trevorsuna** · 0 upvotes > Framework boundaries are easy to confuse with business boundaries. Separating contracts and core logic can make tests and migrations much calmer, though I’d introduce the DI and monorepo rules gradually so the structure stays proportional to the product’s actual complexity. **@agustinbarrientos** · 0 upvotes > Do your Nx boundary tests import through barrel files and path aliases, or can a hotfix still bypass the rule through the shortest path? ## Similar posts on daily.dev - [Front-End Architecture with Domain-Driven Design](https://daily.dev/posts/front-end-architecture-with-domain-driven-design-pzbik3lbx) · iO tech\_hub · 138 upvotes · 11 comments --- Tags: [#webdev](https://daily.dev/tags/webdev), [#react](https://daily.dev/tags/react), [#architecture](https://daily.dev/tags/architecture), [#domain-driven-design](https://daily.dev/tags/domain-driven-design) [View this post on daily.dev](https://daily.dev/posts/why-are-we-talking-about-architecture-again--qeiyintcw)