I will enlist the breakthrough differentiations of Abstraction technology. The full technology wrap up is (still) at http://abstraction.codeplex.com
Abstractions are mathematically optimal DSLs that can rely on other DSLs
Each abstraction is a DSL; independent DSL mathematically optimal for the case. Creating maximum value (as much as refined outputs as possible) based on the absolute minimal amount of information.
This means that the hand-written code is reduced to the bare minimum (and actively reduced even further when new candidates are identified).
Because there is no traditional burden of defining the DSL and the binary restrictions applying that constrain the different versions, it frees the abstractions to rely on the following key differentiations.
Multi-level abstraction (that is, an abstraction targeting other abstraction(s) as its output) is a DSL generating output for another DSL(s).
One example could be object-oriented class abstraction generating output for ORM abstraction and for proxy class abstractions.
Combining independent abstractions can provide optional fully compatible features. Standard ORM abstraction can be combined with Authorization Abstraction that will provide object-level authorization, regardless of the underlying ORM technology.
Designing Abstraction Serves as a Design Model
Visual XML Schema editing serves well for the design model for the solution. Not only that but the model documentation in the schema annotation also provides in-place written design documentation as well as serves automatically for XML intellisense when used.
Hence the work required stays at the absolute minimal while the design model is still created and is 100% in sync with the actual implementation.
No Binary Constraints – Everything in sync with code version
Abstractions just generate source code. This means that different incompatible versions of the same abstraction can happily live side-by-side without immediate need to refactor the software to the latter.
This also means that the target for the abstraction does not have to support the abstraction in any way.
Because of flexibility, the solution structures can be actively abstracted further as such possibility is identified.
Deployment and Patching Trivialized, Controllably Customizable
Because abstractions are delivered with source code repository syncing and rely on the branch/merge structures in the enterprise’s own repository, the source control rules apply.
Whenever project level needs to fix a bug, they can do it immediately within their own branch of the abstraction library. This can be reverse migrated by the enterprise abstraction authorities. This also applies to any external provider abstractions, and when the final fix from the original supplier syncs in the repositories, the conflict management in the source control takes care of the change management.
New features to existing software are automatically applied when reference providers update their abstractions.
Industry Reference Abstraction
Everyone can become an abstraction provider; from major industry framework player to a single consultant. Simply allowing access to any public repository allows users to sync the changesets to their private repositories. Based on industry reference abstraction providers, the self-written code and abstractions get reduced to bare minimum.
Everything that needs to be guided as “HOW-TO” can and should be abstracted
Well made abstractions are self-documented pieces of architectural structure(s). No more “this is how you use this feature”.
Abstraction targets don’t stop at source code. Configurations, deployment, everything that can be derived from the logically extractable information is a candidate.