Simple architecture

Build independent [low-level] modules and integrate them on top [high-level] modules.

Simple architecture design

• simple architecture: an alternative to clean-architecture.
• modules dependencies: high-level modules --> middle-level modules [optional] --> low-level modules [modules pyramid].
• high-level modules integrate all low-level modules and mid-level modules: domain integrations here, here and infrastructure integrations here.
• middle-level modules relies on low-level modules having lower complexity than high-level modules.
• low-level modules completely independent ["parallel" modules].
• low-level modules could share some modules [ex. simple.domain.models].
• low-level modules should be most of all modules [pyramid base].
• low-level modules should be seen as lego pieces and high-level modules as lego structures.
• fractal design could be applied at any level:
  • server projects simple projects.
  • front-end modules react-like library.
  • front-end components identity app.
  • functions aspnet-like security library.
• simple architecture aka pyramid architecture.

Simple architecture implementation

• high-level modules: simple.domain.integrations, simple.infrastructure.integrations.
• low-level modules: simple.domain.services, simple.infrastructure.emailserver, simple.infrastructure.jobscheduler, simple.infrastructure.mediator, simple.infrastructure.mongodb, simple.infrastructure.queue, simple.infrastructure.sqlserver, simple.domain.models [shared].

Simple vs clean architecture parallels

• the dependency rule != no dependencies [even callback funcs could be seen as a form of dependency].
• entities != simple data bags [simple.domain.models].
• use cases == simple.domain.services.
• interface adapters == high-level modules.
• frameworks and drivers:
  • low-level modules [databases drivers].
  • high-level modules [web frameworks].
• pyramid vs stack => simple vs complex => unknown [yet] vs highly-appreciated [?!].

Simple vs clean architecture dependencies

• clean-architecture implementation:
  • clean.architecture.core project depends on Mediatr package [?!].
  • clean.architecture.usecases project depends on clean.architecture.core project and EntityFrameworkCore package [?!].
  • clean.architecture.infrastructure project depends on clean.architecture.usecases project [?!].
  • clean.architecture.web project depends on clean.architecture.infrastructure project [ok].
• other clean-architecture implementation:
  • domain project depends on Mediatr package [?!].
  • application project depends on domain project and EntityFrameworkCore package [?!].
  • infrastructure project depends on application project [?!].
  • web project depends on infrastructure project [ok].
• simple-architecture implementation:
  • simple.domain.services, simple.infrastructure.* completely independent projects [share simple.domain.models project].
  • simple.domain.integrations and simple.infrastructure.integrations projects independent of each other, depend on all above projects.

Remarks

• similar architecture already exists [how else :)] IODA architecture.
• operations = low-level modules funcs [ex. database funcs].
• integrations = high-level modules funcs [ex. webapi endpoints].

Credits

• Eric Evans: autonomous bounded contexts DDD.
• F# team top-bottom dependency order.
• Mark Seemann's mindset changing hidden gems:
  • impureim sandwitch.
  • dependency rejection.

SIMPLE ALWAYS MEANS SIMPLE