The first entity we encounter while working with Epic is the Enterprise. It’s a singleton, a static class that must be initialized before use.

In the initialization we have to provide an implementation of the abstract class EnterpriseBase. Such implementation will be tailored to the concrete application that will use the domain, providing access to the environment and to the corporate organization.

The abstract methods RetrieveEnvironmentInstance() and RetrieveEnterpriseInstance() are not simple factories: they incapsulate both the knowledge of the right types to use, their initialization techniques and their livecycle.

Being a static class coupled with EnterpriseBase, Enterprise is the trick to do things properly down to roles, since you have to use the base classes provided, with all the connected long term benefit.

Each company operates in an environment. From the company point of view, such an environment (physical, social and economic) provides a range of services that are crucial to its success. Buildings, roads, laws and electricity are simple yet evident examples.

The model of that company’s core business can not be that different.

Indeed it needs to be stored and tracked for example. While writing pure POCOs, a modeler shouldn’t consider neither persistence nor logging. Yet, the application must do both!

Epic.Proxy provides autogenerated proxies to inject the infrastructure in the domain entities, but how to retrieve such infrastructure? How to access the ADO.NET connection or the log4net.ILog to use?

The IEnvironment interface provide access to this kind of services. It’s a sort of service locator but its use is only for entities' proxies and infrastructural code: no entity or value object should ever depend on IEnvironment.

The IEnvironment instance is accessible from the Enterprise.Environment property, that ask to the EnterpriseBase implementation provided during the initialization. EnterpriseBase forces the environment to implement EnvironmentBase that make it a serializable singleton.

EnvironmentsChain and EnvironmentChainLinkBase are building block for environment’s configuration, although it is perfectly legitimate to derive EnvironmentBase directly.

To access the domain models, each corporate member has to enter in the organization. After the authentication, the users start their own working sessions and begin to achieve their roles.

The abstract class OrganizationBase helps with the implementation of the IOrganization interface, providing a set of template methods to handle working sessions lifetime.

To design IWorkingSession we analyzed a tipical working day in a successful company. Each day a lot of smart people enter in the company and start their own tasks. Each person has specific responsibilities and roles. Each role provides access to a set of resource and services that are required to complete a set of tasks. Most resources require exclusive control for an amount of time (did you say "the bathroom"?) but a few (hopefully very few) require concurrent access and realtime synchronization.

WorkingSessionBase is the base class to extend for describing working sessions. It defines a set of template methods that enforce some important invariants.

For example, we have to define when a user IsAllowed() to access a role or what to do BeforeDispose(). But the most important abstract method that we must implement is GetRoleBuilder(). It returns a RoleBuilder that will create the required role for the user performing the working session.

RoleBuilder is an abstract class that can not be derived directly, but through RoleBuilderBase. These two classes enforce a controversial rule: the clients must use the roles through pure interfaces designed without any constraint, but all concrete roles must derive RoleBase, that is an abstract class serializable and disposable. Indeed roles' serialization and their disposition will be required from the framework, as we will see in Epic.Poem.