n the past few years, I've grown to enjoy more and more programming in a functional style. Even the java code I write nowadays is mostly free of mutable state. But before that, I spent a good chunk of time learning about object orientation and found some great ideas there. Ideas that can carry over to the functional world. One of them is Domain Driven Design, where we strive to have the symbols in the code respresent conncepts in the domain. Of course, I'm oversimplifying DDD, but the ideal of a bijection between the reality our software models and constructs in a programming language is one I believe we should maintain in many, perhaps most, applications.
A natural consequence is that our systems architecture tends to resemble an onion, with the domain model in the center and code to make it interact with the rest of the world surrounding it:I've labeled the code that interacts with the rest of the world "Adapters", as it should do little more than adapt external representations into concepts the domain model can understand. This architecture is not in any way novel. In fact, it is a version of Alistair Cockburn Hexagonal Architecture. In the common case where the only interactions the domain model has with the rest of the world are through a Database on one end and an User Interface on the other, we've just described the 3-layer architecture that was so popular in the 90s. Some examples of adapters are — to increase our shot at the buzzword bingo — Web MVC Controllers, Repositories or DAOs, message endpoints, GUI listeners, etc., you get the picture.
Since Scala is a truly hybrid language, marrying quite elegantly OO and FP, it would appear to be the perfect vehicle to write this kind of software. I've found this premise to be correct, for the most part. As you might have guessed, there is an exception; (If there weren't, I wouldn't be writing this post, would I?). The problem is in the code for the adapters. As mentioned, they tend to be simple shims, translating some external representation into domain objects. Coding such translations every single time for every adapter instance in every application is very dull. We desperately need our old friend, lady abstraction, to help us out here. In the Java world, she lends us a hand though dynamic reflection, allowing the construction of objects and invocation of methods to be done generically. Unfortunately, Scala has no reflection API, so we have no alternative but to resort to Java reflection, in a sense reverse-engineering the Scala compilation process.
This isn't a major gripe, as Scala constructs tend to map to Java constructs in a straightforward fashion. Also, rumor has it that a Scala reflection API is being developed for 2.8.1. But that's only half the story. Powerful as it is, dynamic reflection alone is not enough to solve the Adapter problem once and for all. We often need to parameterize the translation in some way. For instance, when translating objects to database rows, we must discover the Column names corresponding to object properties. In many cases we can trust convention, for instance we could expect the columns to match exactly the names of the properties. But in other cases there is no option but to somehow configure the translation with an explicit mapping.
In the Java world this kind of thing used to be done with verbose and annoying XML configuration files. As the language evolved, annotations were introduced, and they are now the main way to configure such translations.
Annotations are a great improvement over external XML files, but they can't be the end of the story. There is the relatively minor issue that annotations pollute the domain model we strive so much to keep clean and organized, specially when the same domain objects will be active in many adapters. Beyond that, there is the larger problem that annotations are just metadata. Sometimes we want to parameterize our adapters in richer ways. Take, for instance, the proposal for a typesafe API for database queries to be added to the new version of the Java Persistence API. It requires a special pre-processor to generate a metamodel that can be used to parameterize a database adapter.
A better and more generic approach would be to have the language itself provide this metamodel: a kind of static reflection. I would love to see something like this in Scala. Some time ago I toyed with the idea of writing a compiler plugin to provide a static meta-model of Scala classes, but apparently compiler plugins have issues with non-transparent code generation.
Postscript. As with all matters regarding programming languages on the web, we must tread lightly. I am not ranting against Scala, in fact I rather enjoy it, as can be gleaned from some of the previous posts. I am only relating a very specific domain where I believe the language can be much improved.
Your images seem to be broken links to Google Docs that I don't have access to...
Two words: Eclipse EMF
It's the best way I've seen to code a domain model.
Sorry for the mishap, the images should be correct now (thought a tad too ginormous, I'll correct this later)
This could be done trivially if all constructs of the language where allowed as generic arguments.
Well, actually all you need are dependent types and functors since all other elements can be encoded with those two.
Could some of the things you are looking for be resolved using the undocumented scala.reflect.Code feature?
@Rodrigo Kumpera -- But what would be the values inhabiting those types? Maybe something like the (IMO) hackish Manifest mechanism?
And the frontier between "normal" type-systems and dependent type systems is not an easy one to cross.
@Anonymous Thanks for the pointer. Expression trees are certainly one way to do static reflection, and they could probably be exploited to do everything I outlined. But I still do like the idea of having an explicit metamodel.
Ãh? Arquitetura da cebola? Muito aplicados os temas daqui, passei pra olhar só de curiosa. Gostei das citações do post anterior. :) Bjo
AFAIK there is a reflection API, now. I'm not sure if it is still experimental but there is something to start with.
air bangs long hair extensions curly hair, hairdressers said thathair extensions sale this hair is relatively wild, and the operation is relatively simple, the hair extensions uk color can also have a variety of options, for a higher number of lush hair extensions girls, this kind of wig sets perfect.
Enjoying and exploring will give you a lifetime experience.
how to use ors hair mayonnaise
bio oil for skin lightening
dudu osun black soap before and after
Nice post! Acadecraft has a team of experts that have the experience and knowledge to answer intrinsic questions in a detailed and step-wise manner. Our team of manual designers answers every question accurately.
manual development services
video solutions development companies
higher education services provider
That's a great article! The neatly organized content is good to see. Can I quote a blog and write it on my blog? My blog has a variety of communities including these articles. Would you like to visit me later? 온라인홀덤
Fantastic website. A lot of helpful info here. I am sending it to some
friends ans additionally sharing in delicious. And obviously, thank you to your effort!
my web page; 대구오피
This is the perfect post.메이저토토사이트 It helped me a lot. If you have time, I hope you come to my site and share your opinions. Have a nice day.
Your information was very useful to me. That's exactly what I've been looking for 샌즈카지노!
As I am looking at your writing, 파워볼사이트 I regret being unable to do outdoor activities due to Corona 19, and I miss my old daily life. If you also miss the daily life of those days, would you please visit my site once? My site is a site where I post about photos and daily life when I was free.
Many thanks for the article, I have a lot of spray lining knowledge but always learn something new. Keep up the good work and thank you again. 먹튀사이트
koupit řidičský průkaz
acheter permis de conduire en France
belgisch rijbewijs kopen
comprar carnet de conducir
rijbewijs kopen online
Post a Comment