InfoQ Homepage Domain Specific Languages Content on InfoQ
-
8 Reasons Why Model-Driven Approaches (will) Fail
If you want to start building software in a model-driven way you’ll need to devise some methodology based on ideas and practical experiences from others. In this article, Johan shares with us 8 gotchas of Model Driven Engineering. The article contains a rich set of references to help you go further in your investigations.
-
Beyond SOA: A New Type of Framework for Dynamic Business Applications - Part II
In this second part of their article, the authors explore the architecture of Dynamic Business Applications and introduce the concept of a Resource Container. They demonstrate how this architecture can be layered on top of JEE and how it impacts implementation productivity.
-
Best Practices for Model-Driven Software Development
Model-driven software development no longer belongs to the fringes of the industry but is being applied in more and more software projects with great success. In this article we would like to pass on, based on the experiences we have gathered in the past few years, our contribution to its best practices.
-
Domain Specific Languages in Erlang
Erlang is well known for it's concurrency model and fairly well known for robustness. But what about other aspects? In this article, Dennis Byrne shows how to use Erlang for creating internal DSLs.
-
Domain Driven Design and Development In Practice
In this article, Srini Penchikala discusses Domain Driven Design and Development from a practical stand-point. The article looks at architectural and design guidelines and best practices that can be used in a DDD project. It also talks about the impact of various design concerns like Persistence, Caching, Transaction Management, Security, Code Generation etc in domain model implementation effort.
-
Building Domain Specific Languages on the CLR
In his latest article Ayende Rahien introduces internal DSLs as a means of creating Domain-Specific Languages without having to deal with the complexity of designing a completely new language. He compares different .NET languages as suitable host languages for DSLs and presents Boo as an ideal candidate due to its meta programming facilities, flexibility, and performance.
-
Beyond Foundations of F# - Asynchronous Workflows
Robert Pickering continues the conversation in this third article on F# and this time focuses on Asynchronous Workflows and the resulting peformance gains obtained when used. While this article focuses on F#, the learnings are applicable across .NET languages.
-
Architecture as Language: A story
Architecture is often described non-tangible in Word documents or entirely technology-driven. Both are bad, but what can be done? Markus Völter describes how to evolve a language around your architecture, a formal language that as a side effect ends up being a good base for generating important parts of the system.
-
An Approach to Internal Domain-Specific Languages in Java
Alex Ruiz and Jeff Bay describe how it is possible to write domain-specific languages using the Java language and suggests some patterns for constructing them.
-
Beyond Foundations of F# - Workflows
Continuing Robert Pickering's series of articles on F#, this InfoQ exlclusive article focuses on workflows in F#. Workflows are the building blocks for library implementers interested in the basics of DSLs.
-
The Seven Fallacies of Business Process Execution
After 8+ years of intense research, the promises of BPM have not materialized: we are still far from having the ability to use the business process models designed by business analysts to create complete executable solutions. Some argue that we need to re-engineer BPM standards. In this paper we explore a new architecture blueprint for BPMSs that offers a cleaner alignment between SOA and BPM.
-
Interview: IBM Architect Bertrand Portier on joining MDD and SOA
In the wake of the latest product announcement from IBM, InfoQ talked to Bertrand Portier about a RedBook that presents a Model-Driven-Development approach to service construction. The concepts are general enough to be applied to product stacks other than IBM.