Technologist Career Management System
The Data Services Layers
As a review of the last TCMS installment:
The TCMS consists of two domains:
Services Domain – The Info Services for Database and Cloud Service Data
The Application Domain – The MVC Design Pattern that Consumes Info Services
The Application Domain is an MVC 4 Web Application. It Uses the MVC Architecture to manage Interactive State Data.
The Services Domain manages the information from a Data Repository and Cloud Services.
This information is formatted into Complex Composite Data Transfer Objects (DTOs) that contain the Data DTOs and its Error and Exception Handling object.
The TCMS Sub-domains
This section will introduce you to the “Sub-domains”:
The Services Data– A Relational 3rd Normal Form Data Model in a SQL 2012 Database sub-domain
The Data DAL – The Object Relational Mapping (ORM) Data Abstraction Layer (DAL) for the Services Data sub-domain using Entity Framework 5 as its ORM
The Data Ops – The Anti-corruption Data Operations Layer (DOL) that consumes the Data DAL sub-domain.
This sub-domain is providing all the Information Data Transfer Objects (DTOs) for Client Consumption with their Error and Exception Handling Object.
The Data Ops sub-domain abstracts the SQL Database from the Data Ops sub-domain
These three sub-domains create the Services Information Data Services Component:
The Services Data Sub-domain
The Data Model is organized into a database relational representation of the Domain Driven Design (DDD) Business Entities.
There are Four Relational Data Models in the TCMS Data Model:
The Assessment Data Model– Holds the assessment results as the Highest level Domain Entity
The People Data Model– Holds the Candidates information for the Assessment results
The Skills Data Model– Holds the Technology Skills that a Candidate is being assessed
The Questions Data Model – Holds the Skills and Assessment questions used to assess Candidates
There are three types of Data Tables in the diagram
Entity Tables – These are the primary information data tables. They provide an Identity for the DDD Entities
Look-up Tables – These tables provide the information for the DDD Value Objects. The Look-up tables hold all the related information without any identities to and Entity
Bridge Tables – These tables, sometimes referred to as “Link” or “Join” tables, create the ability for the Entities to create Collections of Value table information. They create a “One-To-Many” Data Model relationship
Each of the Four Data Model Entities and their supporting Aggregate Value tables are displayed below:
The Data DAL Sub-domain
This layer is the Object Relational Mapping component. Using Entity Framework, the Data Abstraction Layer manages all the database operations.
The Domain Entity Class Object Model:
The Entity Class Model creates classes that represent the Relational Data Model within the SQL database.
It simplifies the Class Object Model for consumption through its own evaluation of the SQL Data Model when it creates the Class Object Model.
Notice that simple Bridge Tables within the SQL Data Model do not exist within the Class Object Model. The ORM understands the Many-To-Many Relationships and can manage all of the required operations without the consuming client‘s understanding of the Bridge Tables.
More complex Bridge Tables, such as the Triple Keys Tables are represented as they have “Forking” options that do need Client consumption understanding.
Color coding in Entity Framework 5 clearly identifies the Domain Entities as defined in the Domain Driven Design.
This sub-domain delivers clean access to the Domain Business Objects for consumption in the next higher sub-domain: Data Ops.
The Data Ops Sub-domain
The Data Ops sub-domain is the Transformation Layer for the raw ORM data to the ResponseDTO data.
Direct data access to the ORM class objects provide the raw source data for the domain business objects.
The Data Transfer Objects (DTOs) that carry the “Data Payload” to the requesting Client is transformed from the Raw ORM data.
These ResponseDTO objects are far more complex than the simple class objects returned from the Data DAL sub-domain ORM.
The Business Services Component services processes the RequestDTO from the consuming Client application and responds with a ResponseDTO state object as a single “Big Box” data payload package.
The Composite Request DTO “Big Box” Contains:
RequestCommon – This is a base Class State DTO that holds all common properties. These are properties that consumed the Cross Cutting Concerns of Info Services: Logging and Messages
RequestDTO – Data Ops receives the RequestDTO as a derived class of RequestCommon that contains the parameter object of primitives and Collection Aggregate DTOs required for the Data DAL ORM call
Data Ops transforms the Raw ORM Class Object Data into the Complex Composite DTO: ResponseDTO
The Composite Response DTO “Big Box” Contains:
ErrorCommon – This is a base Class State DTO that holds the Error Handling Object and Interface Extension Methods. Interface Inheritance, Composition, is employed to access the Behavior methods for Error and Exception handling
ResponseDTO – Data Ops returns the ResponseDTO as a derived class of ErrorCommon. This Return Complex Composite DTO is the Container for all Primitives, Collections and the Base Class Error Object that holds all Error and Exception information
The Request and Response DTO Details
Think of the RequestDTO and ResponseDTO as objects sent to and received from a Product Warehouse.
The Consuming Application is the Business that has placed an order for product replacements for its Inventory
- The Order Request – An order is created in the form of a RequestDTO. This order contains all common order information such as Customer ID, Shipping Address etc. and the information for the replacement products.
- RequestCommon – Common Order Information
- RequestDTO – Replacement Products Information
- Delivery Truck Order Response – The requested Order is received on the Shipping Dock in a Single Package. This package has numerous other packages within the “Big Box” package
- ErrorCommon – Holds any Backorder Information and other issues that are Global in nature to the Order Request
- ResponseDTO – The “Big Box” that holds the Global Information Box and all the other Collection boxes and the loose item primitives that are required to complete the Order Request
The “Big Box” encapsulates all of the Order Requested response entities in one location. The Shipping dock can deliver a single object to the requesting department easily.
The receiving Department can take what “Boxes” it needs and pass the “Big Box” to other consuming Departments.
The Box can also be “Stored in the Warehouse Cache” and used later as required.
All the Global Back Order and other information is readily available for all of the consuming Departments to read and respond.
The major advantage of the “Big Box” paradigm is the Error Object.
It contains Interface Extension Methods that create “Bubble Up” Error and Exception Messages in a Collection that can be iterated using its Index.
The index zero is the lowest abstraction module layer and the Error List count minus one is the highest or last error received.
This creates a valuable resource for User Interface displays and Architecture Logging and Troubleshooting.
The Highest Level Messages can be Designed as Meaningful User Interface Informational Notices
These possibilities only exists because of the Complex Composite DTO design.
This paradigm does not exist within the Entity Framework ORM when data is called directly
The Big Box Paradigm with its Error Object
… Is Why The Modern Developer
…… Uses a Complex DTO Transformations
The Next Installment of the TCMS Solution
…… The Messaging Module