4 thoughts on “Metadata-Driven Design: Creating an User-Friendly Enterprise DSL

  1. Just read the InfoQ article. Excellent piece. I’ve been thinking a lot about the subject for the past year or so and have finally started on the project of implementing a DSL. After only 2 weeks of investment I am already reaping huge benefits from the UI-generation. It’s a beautiful place where you can write a C# class to handle a business transaction and the UI is auto-generated for you without any need to write any ASP.NET controllers/html or javascript.

    I am VERY curious as to why more people don’t talk about this and why is this not a mainstream thing that we do? Are the best devs keeping this secret to secure their jobs/clients?

    Liked by 1 person

    1. Many thanks for the compliments, Nik! They are most appreciated.

      That’s a good question regarding why DSLs are not more mainstream, and unfortunately, I believe that it’s not a popular option for many developers. In my opinion, there are multiple reasons that constitute the answer:

      1.) Writing a DSL is more of a commitment. A DSL can be incredibly powerful, but at the same time, you are now bound to your own creation when trying to further the implementation of your project. In comparison, when it’s just lines of code, there is more freedom to make adjustments.

      2.) Writing a DSL is more of an investment, for both the developer and for the manager. For the developer, it will require more work, and in some work environments where time is not plentiful, it is seen as more of a convenience than an imperative. Since it’s not popular, managers have a much harder time when attempting to justify that approach to any superiors. Of course, that’s assuming a manager has taken the time to understand the benefits of such an approach. I think that some companies (where software is the core business) might entertain such a choice, but in cases where software is only a supportive role, it would not meet consideration.

      3.) Writing a DSL goes against general trends. Decades ago, the general trend was to write as much as possible by yourself. (In those days, it was often necessary since open source projects were scarce.) However, it seems to be the opposite today, as developers use effective, quality packages that do much of what is needed. The downside is that there is a general inclination to not embrace any complexity that passes a certain threshold. In this case, it’s more of a psychological issue resulting from a zeitgeist of contemporary developer culture.

      Of course, you could attribute the same reasons above as to why MDD might not be a popular option. Out of curiosity, did you use MDD when you created your own DSL?

      Like

      1. I just realized that I was commenting to the wrong article. The one I originally read: https://www.infoq.com/articles/mdd-webapi-for-mobile-apps.

        So I guess I misunderstood the idea of MDD slightly. I was only focused on the UI part of it, i.e. – dynamically generating UI based on metadata. This is what we are trying to do in my team. We haven’t really thought about doing MDD for the business logic yet, because we already have a rather large codebase and it would be a risky and expensive undertaking at this time to refactor everything.

        Our goal at this time is to use MDD for generating UI only. We want to avoid having to write custom html/javascript for each new functionality we add in the business layer. Currently the business layer follows a CQRS pattern, so basically we have a set of “commands”, each encapsulating a single business transaction. What we started doing is augmenting each of these commands with minimal amount of metadata (within code). In the UI layer we created a very simple rendering engine, which can then process the metadata and render each command appropriately.

        We are still in the *very* early stages of this design, but it seems like the right way to go.

        Liked by 1 person

      2. Actually, I would say that you understood MDD perfectly! On our production system, we had wanted to incorporate MDD into all aspects of our distributed architecture, including our front-end application. In the end, though, the front-end team ran out of time, and they could only partially incorporate it into the UI design. If you can build a complete UI with it, that will be a first!

        Are you keeping the metadata within the code for easy maintainability, or is it for another reason? In any case, I’m very curious to see how MDD fares in your case and if it still serves you well later in your project. Please keep me informed! And for any other comments or questions, you can always reach me at my LinkedIn account.

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s