A Hybrid .NET Technology Stack
using the MEAN.js Framework
|Dilemma||Hybrid Stacks||Forces||Mean Stack||Entities|
|Select a content section anchor button and then use the Browser’s back button to return to selections|
New Technologies and Legacy Systems
The rapidly changing technology ecosystem promises our Clients features and functionality for the Customer base that is very attractive.
Unfortunately implementation of most of these glorious outcomes are better realized in Greenfield Projects.
Most mature Client’s technology ecosystem has been evolving over many years and possible millions of dollars invested.
Proposing Greenfield Projects, as a pathway to the perceived new benefits of the latest technology platforms and frameworks, is going to be a very hard sell if leveraging their existing infrastructure and supporting processes need to be drastically changed or completely replaced.
The Challenge Becomes:
How do we offer the highly publicized
“Bells and Whistles” of technology
breakthroughs while preserving the
invested in their sources the
company already has in place?
We need to offer our Client’s a viable way of leveraging their Legacy Systems accrued dollar investment.
Through a cost effective Hybrid Technology architecture solution, that requires as little change to their current processes as possible, we can safely provide our Clients and their Customers the benefits of the latest Technological Business trends.
A Common Business Dilemma
I recently was asked to help solve a financial company’s issue with their current website.
The company had become aware that even though their Client tool for finding financial advisors search page was their second most hit page, the results of the search netted them less than 6% real quantifiable results.
The feature, as designed, did not meet their Client’s needs
The currently deployed technology could not support the features and functionality that they saw their competition was providing for their Clients.
They decided that they needed to completely replace their client facing technology but had Millions Invested in their Middleware and Backend Technologies that was sourcing data from their Salesforce CRM application and an Oracle CMS Information Repository.
They were Primarily a .NET shop
but had other Technologies as well
The question they asked:
How can we offer modern front-end features for our Clients but still retain the maturity of our middle-ware and back-end systems?
The answer is an Opinionated Hybrid Technology Stack.
Opinionated Hybrid Technology Stacks
What are the Three Forces of Solution Delivery?
Delivering modern technology solutions is more of an Art than a Science.
It requires the Delivery and Client Management Team to manage the Three Forces of Solution Delivery:
- Time: A fixed development duration interval driven by iterated deliveries
- Resources: A cross functional, fixed count team, based on clearly defined team players roles and responsibilities
- Technology: A DevOps driven, cloud-based, elastic development and delivery ecosystem completely controlled by the delivery team, not the Client
The Time Interval, the Delivery and Management Teams Size, the Team Members, the Delivery Process along with their Supporting Environments are all built on Opinionated Tools, Processes and Delivery Strategies.
These constraints create the
Opinionated Hybrid Technology Stack.
They ensure that the
Expected Results are the Delivered Results
How do constraints ensure a successful engagement?
All cost estimates, time to market and acceptance criteria are based on the understanding that the opinionated management of the Three Forces of Solution Delivery are managed by the Delivery Team.
The Client has engaged a Professional Delivery
Group to help solve their current Business
issues so they MUST let the Professional
Delivery Group manage the
Three Forces of Solution Delivery
The Hybrid .NET / MEAN Stack
Microservices, Domain Entities and the MEAN.js Stack
The solution to the above business dilemma begins with creating a modern Service Oriented Architecture (SOA) in the form of an ASP.NET WebAPI 2 Microservices API Layer.
We call it “Microservices” because it sits on top of a Domain Driven Design (DDD) based Entity Technology Domain build that represents the true Business Entity Domain in its Organization of Business Information.
Each Business Entity is a core function of a Business Vertical Component that is accessed through its Independent REST API Resource.
The Business Entity is represented as a Domain Identified Collection of Entities and Value Objects that are created and destroyed as a set of objects by a Service call to a Factory that queries the In-memory Repository Cache for the Entity Object Set.
This is achieved using Model Driven Design.
If present, it returns the entire Business Entity to the calling Client.
If it is not present it retrieves all the required elements from the Infrastructure Layer, assembles them, places them in Repository Cache.
It then returns the entire Business Entity to the calling Client.
What are Entities and Value Objects?
– An Entity is an object that could have Global Identity within the Technology Domain by itself
– A Value Object is an object that only has Identity when a member of an Entity Collection
Domain Identified Collection of Customer
The Aggregate Root Entity
A Customer Aggregate Root Entity is a collection of Business Entities
- Root Entity Id
- A Customer Entity
- Customer ID
- First Name
- Last Name
- Customer Type
- Customer Addresses
- Customer Emails
- Customer Locations
- Customer Websites
- Customer Industries
The Customer Aggregate Root Entity has an Identifier that has Global Domain identity and represents all of the Entities and Value Objects within its collection.
The Entity is stored as an object that can be created and destroyed at will.
The Collections has One Entity: The Customer
The Customer Entity could have global identity as it has a Unique Id that represents a Single Business Object but it would be void of true substance without its Collection of Value Objects.
Its Collections of Addresses, Email Addresses, Locations, Websites and its Participating Industries make up the Value Objects
None of the above Business Objects serve any real business purpose by themselves, they take on true value as a member of the Client Aggregate Root Entity Object.
This is the power of Domain Driven Design and the framework that allows us to encapsulate Business Object Collections as Independently Manageable Microservices Offerings.
A Client is free to consume all of the provided
Business Object Collections or a
subset as required as each resource
is managed as an independent RESTful
resource completed decoupled
from any other Domain Aggregate Root Entity
All life-cycle management, upgrades, feature enhancements and versions are also independent.
This allows Entities to develop, or be completely replaced, without any residual effect on any other Domain Entity.
What is Data Impedance Mismatch?
Application “Data” being referenced in this context are Object Structures that encapsulates Application State defining Information Fields as Properties using “Nouns”.
Data Object Structures do not contain
Action Behavior methods as “Verbs”
Interestingly enough, the term “Impedance“, now bandied about in software engineering circles, is borrowed from the Electronics Industry.
Impedance is the Measure of the Amount that some Object impedes, or obstructs, the flow of Electrical Current
Impedance might refer to Resistance to current, Reactance to the current as in a Coil, or some complex combination of the two
An example to illustrate impedance mismatch:
Imagine you have a low current flashlight that normally uses AAA batteries.
Don’t try this at home, but suppose you could attach your car battery to the flashlight.
The low current flashlight will pitifully output a fraction of the light energy that the high current battery is capable of producing.
Likewise, if you attached the AAA batteries to Batman’s Spotlight, you’ll also get low output.
However, match the AAA batteries to the flashlight and they will run with maximum efficiency.
Back to software engineering:
Imagine the flow of Data to be analogous to a current,
then the impedance of a Relational Data Model
is not matched with the Impedance of a ORM Object Hierarchy.
The Data will not Flow with Maximum Efficiency due to the Impedance Mismatch.
Data Impedance Mismatch in our Hybrid Stack
The Node.js Application Layer processes the required Business Logic, if any, and sends the resulting JSON to the Mongoose Schema Middleware.
This action will create a Schema-free MongoDB Document as a Binary Representation (BSON) of the JSON Data.
The formated JSON object then store it in MongoDB Primary Database Server as a BSON Document.
No Impedance Mismatch on a Database Write
A Query is created, in JSON format,
and sent to the Express Node.js Web Server
The Node.js Application server processes the required Business Logic, if any, and sends the resulting JSON to the Mongoose Schema Middleware as a MongoDB Entity Filter Request.
MongoDB returns the results to Mongoose to format into a
Read-only Relational flat object JSON Entity
This creates a Complex Nested JSON Object that
Represents the Requested Data Set
The Node Express Web Server delivers the Requested Response as Serialized JSON for Deserialization n the Client within the Angular AJAX HTTP Service for the Controller to pass to the Visitor’s view within the $state injected object.
No Impedance Mismatch on a Database Read
The Isolation Abstraction Layer
Our ASP.NET Web API 2 RESTful Microservices acts as an Isolation Abstraction Layer.
By using a Domain Layer to assemble Cachable Entity State Objects and the Web API with a RESTful HTTP Uniform Interface we can create a design that does not compromising either the Greenfield Technology Stack or the Brownfield Legacy of Technology Stack.
If the Legacy .NET Stack does not have a Domain Layer to create our Aggregate Entities we must create one on top of the existing Data Access Layer (DAL) or Repository Layer. The ASP.NET WebAPI 2 Microservice API can then serve as our Isolation Abstraction Layer.
The Domain Entity Layer
The Domain Driven Design Domain Layer connects the Legacy Infrastructure Data Access Layer and its Repositories to the MEAN.js Stack through the Web API RESTful Microservices Application Layer.
The Domain Layer uses the Command Query Separation (CQS) design pattern with the Request/Response Design Pattern.
Dependency Injection of the Request and the Response Complex Plain Old CLR/C# Objects (POCO) data structures supports Bertrand Meyer’s CQS design pattern.
By using a Service Query that asks the Factory Component for a Complete Domain Entity, from either In-memory Cache or from a Command to the Infrastructure Layer for all Component Data Transfer Object (DTO) POCOs, we can delivery, to the calling Microservice, a completed Aggregate Root State Entity for consumption.
The Factory Component
Aggregate Root Entity,
Injected Response Object,
places it in the
as defined by the
Since the Response Object was injected in the constructor the Factory Component it will return the Response Object, fully populated, to the Service Component for delivery to the calling Web API Microservice.
MongoDB Distributed Cache
The real power of using the complete MEAN.js Stack is the ability to use the MongoDB NoSQL Document-based Data Repository for Globally Distributed Object Caching.
The Node.js Express Web Server will make RESTful Calls to the Isolation Abstraction Layer if the requested object is not in the MongoDB Globally Distributed Object Cache.
The Domain Layer will deliver the requested State Entity Object from either its In-memory Cache or make the call to the Infrastructure’s Entity Framework Data Access Layer for delivery to the Domain Object Factory.
Once the Node.js Application Layer receives the entity it will then place it in the Primary MongoDB for replication within its MongoDB Cluster.
It will then add the Entity name
and its BSON Mongo ID
to the Cache Dictionary
Since this is not an “Atomic Transaction” any minor latency to the Read-only MongoDB Secondaries is irrelevant.
Only one instance of a MongoDB BSON ID can exist at a time due to a call to the Cache Dictionary by Entity Name.
The Globally Distributed HTTP ETag Cache
A Globally Distributed Object Cache is great but what it the object has already been request?
Roy Fielding defined HTTP based caching using ETags, or Entity Tags, way back in 2000 within the Roy Fielding Doctorate Thesis on his HTTP Uniform Interface requirement.
There are Strong and Weak ETags:
- Weak ETag – A weakly validating ETag match only indicates that the two representations are semantically equivalent, meaning that for practical purposes they are interchangeable and that cached copies can be used. However the resource representations are not necessarily byte-for-byte identical, and thus weak ETags are not suitable for byte-range requests.
- Strong ETag – A strongly validating ETag match indicates that the content of the two resource representations is byte-for-byte identical and that all other entity fields, such as Content-Language, are also unchanged. Strong ETags permit the caching and reassemble of partial responses, as with byte-range requests.
In order to persist a Weak ETag as a Strong ETag we using the “M” in MEAN to host our Globally Distributed HTTP Strong ETag Cache.
The major take away from this post should be that Legacy Systems can be consumed by the latest Responsive Design Technologies in a Cost Effective manner.
The use of a Domain Layer with a WebAPI based Microservices RESTful API we can expose Legacy Middleware and Back-end Repositories to a Greenfield Stack such as the MEAN.js.
The difference between the more common “Just replace the Client-side” solutions is that the .NET Hybrid Stack is a “Full Stack” architecture
The Full Stack manages a Globally Distributed Business State Entity Object Cache along with being a Client to the HTTP Uniform Interfaced Web API Microservices that access the Legacy Repositories.
This concept can also be applied to a Java Stack
Thinking outside the box can bring
to your Client options that
were not previously on the table
Wisdom Pearl # 121 – Work Quality Concept
Your Work is Only as Good
… As How it is Perceived by the Next Person who Touches It
Positive Acceptance of your Work is Your Preeminent Responsibility