Feature Driven Architecture

Original idea - by kof

Approach which help to define boundaries for a large application According it we can flexibly adapt and maintain mutable functionality of app.

There are multiple mentions and interpretations of feature-driven approach (see below)

This article contains common rules and principles.

💥By Oleg Isonen (kof) - from React Berlin Talk

• YouTube Talk
• github
• Summary - "Feature Driven Architecture" talk

MISC

• FDD vs DDD
• How to Organize Your React + Redux Codebase
• How to better organize your React applications?
• Why React developers should modularize their applications?
• A feature based approach to React development
• Feature Based Development

UPD (Jan 2021) Also, should be mentioned:

Feature Slices

• github
• github org
• telegram
• Atomic Design
  • https://bradfrost.com/blog/post/extending-atomic-design/
• jsunderhood (twitter)
  • https://twitter.com/jsunderhood/status/1277515984501460992
  • https://twitter.com/jsunderhood/status/1277938445353091074
  • https://twitter.com/jsunderhood/status/1278660547513327616
  • https://twitter.com/jsunderhood/status/1278730782731894786
  • https://twitter.com/jsunderhood/status/1279384660523601920
  • https://twitter.com/jsunderhood/status/1279409800015642627

---

Benefits

• Discoverability - discover how your software works
• Work parallelisation - to dev software by teams, not alone
• Controlling shared abstractions - controlling abstractions, for preventing bugs and controlling software
• Refactoring - we can be sure what user-facing functionality we will affect
• AB Tests - more controllable experiments, with quikly manipulating (many-ifs hell)
• Integration tests - other tests can't cover all app logic, but integration tests is difficult to create and maintain (more meaningful an easy way)

Concepts

• Decentralization - organize app by explicit abstractions, no interconnected monolith (app ⇒ pages ⇒ features ⇒ shared)
• Explicit sharing - explicit rules for managing shared (common used) modules
• Co-location - normalized structure for better project navigation (app, pages, features, shared)
• Decoupling & Isolation - every abstraction should be isolated at most
• Disposability - every abstraction should be optimized for remove, not modify

App structure

└── src/
    ├── app/
    ├── features/
    ├── pages/
    └── shared/

P.S. FDA - not "silver bullet"

There aren't lot projects examples that totally follow defined above rules.

Its caused by very idealistic but hard for impl principles

There is not one approved opinion how to do it (the same problem with DDD approach)

Also

See at FAQ