There are lots of ways of building ADF applications, so there is a very large number of possible architectures. I’ve found that three good architectures are:
In a simple architecture, you build the entire application in one workspace. Business components go into a model project in the workspace, and task flows and pages go into a view/controller project. This approach works well for small applications that will be built by one or two developers.
If your application is larger than 5-10 bounded task flows and/or more than two people need to work on it, a modular architecture is a good approach. In this approach, you place common elements (templates, visual identity, entity objects and view objects for value lists) in a common application workspace and then use the output of that workspace in a number of subsystem workspaces. The subsystems then each contain a specific subset of the total application functionality (view objects, task flows and page fragments), and all the subsystems are collected into one Master application workspace.
If your organization is going to be building many ADF applications, it makes sense to extend the modular architecture to the enterprise architecture. In this approach, you keep enterprise common objects (base-level templates, visual identity, possibly entity objects and view objects for global entities) in an enterprise common workspace and then use the output from this workspace in a number of application common workspaces. These application common workspaces add features that are specific to each application (entity objects and value lists specific to the application). Each application is then built like in the modular architecture with a number of subsystems that are collected into one or more master application workspaces.
Note that the enterprise architecture allows you to build several master applications and even use the same subsystem in two different applications.