[barrkel]

The architectural pattern of implementing a program in a language close to the domain and iteratively transforming it into something that can be consumed in an execution environment long predates OO, and is in fact the principle behind compilers.

It came out in a different guise under Model Driven Architecture and executable specifications a few years back.

It'll pop up again in the future under some other name. The principle is as old as computing itself, though.

[eternalban]

> At the center of the application, semantics are encoded using the language of the domain model.

Say pg/psql.

> Beginning at the center, each layer is translated into one or more languages with lower-level semantics.

ORM mapping into Java?

> At the outermost layer of the application, the final language is that of the application’s environment — for example, the programming language’s standard library or foreign function interface, or possibly even machine instructions.

Or maybe even html+javascript.

Congratulations, you have (re-)invented the layered architecture.

[ubertaco]

>> At the center of the application, semantics are encoded using the language of the domain model.

> Say pg/psql.

Minor nitpick: "pg/psql" is not the language of the domain model. The language of the domain model is stuff like "A car is considered 'All-Wheel Drive' if the drivetrain delivers power to any/all of the axles, not just a single axle."

pg/psql requires translating that domain-model language into something (roughly) like

    set @awdCars := (select * from cars where drivetrainAxles >= allAxles)

[asciihacker]

    > Beginning at the center, each layer is translated into one or more languages with lower-level semantics.
    ORM mapping into Java?

An ORM would not have lower-level semantics would it?

[eternalban]

Lower in this context does not mean 'weaker'. An ORM maps between the lower level relational semantics and higher level object semantics.

[nickpsecurity]

Nah, if it's this topic, more like how AllegroCache object-database maps high-level commands on database manipulation in LISP that look similar to regular manipulation of objects to lower-level LISP that's more efficient which compiles to machine code that efficiently implements those structures on target CPU. Typical ORM's take two things that are very different from one another and never intended to match up then try to force them to match up. Not a great example.

Here's another for you: Lilith. Assembly is messy. So, they create a stack machine (M-code - P-code variant) that idealizes it plus easily compiles to it or implementable at CPU level. Then, they create a 3GL called Modula-2 that's closer to how they express programs but has underlying model of M-code and outputs M-code. In theory, they could go further like 4GL's did to build domain-specific languages that abstract away boiler plate with code generation but still consistent with Modula-2 style. And so on. Easier in functional languages but I'm sure you can see the pattern.

That's what you usually get out of the DSL or interpreter approaches if using a LISP, Haskell, or imperative language designed to make it easy. Languages designed to do them well. A series of transforms with a certain amount of consistency from start to finish. These days, there's even safety techniques for the transforms that they didn't have way back in the day. :)

[lmm]

Only if you can express your domain well in SQL. For most domains you can't, you need a... domain specific language.