The architecture stack for OfficeFloor has three distinct layers:
- Graphical Editors as plugins to the Eclipse IDE that populate the models that configure the Sources (building blocks of OfficeFloor).
- OfficeCompiler which compiles the Sources into the OfficeFrame.
- OfficeFrame which is the runtime to execute the functionality of the Sources.

A Source is like a javax.sql.DataSource to a java.sql.Connection. It is a Source of a particular item used by OfficeFloor. The items are as follows:
- TeamSource
- Provides thread pools for execution of jobs. A thread pool is known as a Team within OfficeFloor.
- WorkSource
- Provides tasks grouped under work that contains the application functionality. There may be many work types within OfficeFloor and each task is a job. A typical example would be: work = object, tasks = methods on the object.
- ManagedObjectSource
- Provides objects which are made available to tasks. Typically the objects are such things as java.sql.Connection, javax.jms.Message, java.nio.channels.SocketChannel (objects you would likely dependency inject).
- AdministratorSource
- Provides duties which can be weaved between tasks. This allows for Aspect style functionality to handle such things as transactions and logging. Each duty is a job.
- SectionSource
- Configuration of how the Work and Managed Objects are connected together. Sections may also contain other sections to break down configuration into managable encapsulated detail. Typically this is represented graphically so that developers and the business can work together on these diagrams to ensure the business requirements for the application are being met.
- OfficeSource
- Configuration of an application. An application is known as an Office within OfficeFloor. An Office provides the details of how the Sections are connected together along with specifying the Administration of any tasks and assigning logical Teams responsible to execute the jobs. The reason for Administration and assigning logical Teams only within the Office is to abstract this away from Sections so that the developer and the business can focus on application functionality in the Sections rather than being caught up with these technical aspects.
- OfficeFloorSource
- Configuration of deploying applications. It is also where this project got its name. An OfficeFloor may host many Offices where each Office is made up of many Sections. The OfficeFloor allows tuning the Offices to the hardware/network it is running on by specifying the physical Teams and Managed Object Sources of the Offices. For example, non-blocking jobs could be assigned to a Team that will have one thread per CPU allowing effective use of the hardware without causing thread contention.
The OfficeFloor graphical editors are plugins to the Eclipse IDE and provide the graphical functionality (via Eclipse's GEF) to configure the Sources. The graphical editors utilise the OfficeCompiler to compile the Sources into 'types' and then graphically configures these 'types' together into the models that make up the OfficeFloor configuration.
Further information can be found in the Eclipse UI module.
Eclipse has been selected due to its wide adoption, GEF plug-in, and most importantly it's free.
The OfficeCompiler loads the Sources into the OfficeFrame. It takes care of validating 'type' compatibility between the Sources so that the constructed application is type safe. This provides fail quickly validation in loading the functionality into the OfficeFrame.
Further information can be found in the OfficeCompiler module.
The OfficeFrame is the core of the Job Based Architecture that gives OfficeFloor its performance.
It simplifies the functionality of an application into Jobs where each type of Job is executed by a particular Team.
Further information can be found in the OfficeFrame module.