Usecases

• Also known as

  • Services

  • Application

• These should be thin, one usecase class per business flow

  • Avoids broad and fat Usecases

  • Easier to find

  • Simpler to test

  • Reduce amount of dependencies

• All dependencies from outer layers (databases, 3rd party, ui etc) shoul point toward the use cases

  • Thus interfaces should be in the same package/module as the usecase

  • Easier to mock out these dependencies

  • Use case only changes when business rules change, rather than infrastructure does

• Can model domain how we want

  • ie domain driven design