The Layered Architecture principle states that components in one layer should only know and interact with components that are in the layer directly below it, and that components in each layer, should only serve components that are in the layer directly above it. This means that in a strict-layering practice, layers will communicate in a top-down fashion from Presentation -> Services -> Business -> Data.
It is often easier said in theory but spells a lot of confusion to developers, especially to beginner practitioners, when it comes to implementation. To help visualize the components' relationships and interactions better, I have developed the following diagram and provided some basic guidelines.
Legend
| BE | = | Business Entity | BC | = | Business Component | SI | = | Service Implementation |
| Enum | = | Enumerations | WFA | = | Workflow Activity | MT | = | Message Type |
| DAC | = | Data Access Component | WFS | = | Workflow Service | UIC | = | User Interface Controller |
| DA | = | Data Agent | SC | = | Service Contract | UI | = | User Interface |
When designing component interactions, use the following guidelines:
Shared
- An entity may contain other entities. i.e. Order with a List<OrderItem>
- An entity may use one or more enumerations for its properties.
- All components in the layer can reference entities and enumerations.
Data
- A data access component should refer to a Table or View in the database.
- A data access component may manage more than one related tables i.e. Orders and OrderItems.
- A data agent should be used to manage the access to external services (known as Service Agent)
- A data agent should be used to manage access to files (known as File Agent)
Business
- A business component should call more than one data access components. One-to-one mapping of business component to data access component is an early indication of something is amiss.
- A business component may call a mixed of data access components and data agents which may also be called by other business components.
- A business component may have some or all of its methods exposed as workflow activities.
- A workflow activity should map to one business component method (although mapping to more than one is OK but not recommended).
Services
- A service may call one or more business components.
- A workflow service usually contains more than one workflow activities to construct workflows.
- A workflow service may contain workflow activities that are exposing methods from different business components.
- A contract exposes a service (if using WCF).
- A service may have more than one contracts (if using WCF).
- A contract may use message types to consolidate data into request or response messages. In this case, they can be data contracts or message contracts. Message Types can also be used for WEB API.
Presentation
- A controller may call one or more services through contracts (If using WCF).
- A controller may call into a service (when WCF is not used).
- A controller may call a mixed of contracts and workflow services. (WFS are actually WCF).
- A controller may be called by more than one user interfaces.
- A user interface may call one or more controllers which may be called by other user interfaces.
Framework
- All framework components can be called by components in one or more layers.
Take note that these are just the guidelines I tried to practice in strict layering. In a relax layering practice, the guidelines should be less rigid.
This is the 5th posts in my Layered Architecture series. You can also catch the other posts:
No comments:
Post a Comment