Chapter 10. Epic.Core

 

An enterprise system is a system that supports the day to day operations of an enterprise or organization in real time.

 
 -- Strong D.M. & Volkoff O. A roadmap for enterprise system implementation (2004)

At the core of the Epic framework there is a model of the corporate that uses the software. It’s a quite simple model, a generic one, that describes a well defined context: the corporate daily life.

Indeed, our applications target the core business of our customers. The way each user approaches the application depends on the roles he plays in the organization. It is not simply a matter of access control and security, every instance of the software runs under the responsibility of a specific person, and different people will have different kinds of tasks to execute.

Such models are contained in the Epic.Core assembly: under the Epic namespace you find a set of interfaces and abstract classes that leaves you all the flexibility you could need but forcing important invariants that could be missed during the development.

[Note]

This chapter is still under development. Please send us feedback, questions and suggestions.

The company, first

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 benefits.

The environment

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.

The corporate organization

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.

Yet another working day!

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.