Java introduction

DSL Platform has a compatible client library for Java and can maintain domain model on top of it. Javadoc for client library can be found here. Source for the client can be found at Github.

This means that DSL Platform can maintain all boilerplate code, keep it synced with the model and let developer focus on other important tasks. What is different in DSL Platform approach vs other solutions?

There are three main approaches to reducing boilerplate on the client side:

  • with the rise of Javascript and NoSQL solution dynamic model became very popular. Client code can be dynamic - unsafe, which usually looks like:

    ServerObject obj = new ServerObject("MyObject");
    obj["value"] = 5;;

    There are obvious disadvantages to this approach, such as type-safety, so let's look at another one.

  • code generators are another popular approach, but not used as much because of code ownership issues. Since usually generated code needs to be modified by hand it is very volatile. While some languages have workarounds for some problems (C# has partial classes), they are never a complete solution.

  • DSL Platform takes approach of library compilation. Since generated code should never, ever be modified by hand, it's better to provide it as a library. When necessary, library code can be used for debugging purposes.

What do developers get in return?

Since major part of the client code is compiled from a DSL model, even if other languages are not used in this project and much less code is maintained what are the benefits of writing projects this way?

  • type safety - besides Java static types, all kind of guards are added to the code. Null checks, length and scale checks and various other kinds of checks are embedded inside the compiled library, so errors will be detected as early as possible.
  • domain language - same language is utilized in database, server and client libraries. Since DSL model defines the language, there is much less miscommunication.
  • api - best practices and patterns are embedded in client library and server API. Helper methods make the code more readable and easier to reason about.
  • server infrastructure - persistence, reporting, data analysis and all kind of features are available through a simple API since all of it has been prepared by compiling DSL model to various components.
  • project evolution - database, server and large portions of client code can be maintained from DSL model. DSL Platform will upgrade database automatically whenever required. It's safe to change table and column names, drop and add columns. No scripts for database migration are required. This makes it very convenient way to explore domain in early stages and very easy to add new features and change requirements later in the project.

If this is so cool, why it's not used more often?

Well, that is a hard question to answer. Ideas about declarative programming go a long way back. This is not new stuff. Only the implementation is new. Combination of several different technologies and their unique features was required for this to work.

ORMs and relational only databases are partly to blame that people have given up on trying to have same model in the database, server and client code.

LINQ is great type-safe addition on general purpose languages which allow for easy and convenient conversion to SQL queries, so declarations can be very DRY.

Ultimately, focusing on the developer and providing textual representation of the model, instead of UML or various other GUI modeling tools is the tipping point which allows for describing and utilizing programming patterns and concepts in a very consumable way.