About 3 years ago I got in love with the very concept of Domain-Specific things. Languages, frameworks, whatever…

At first I thought it would be great to model the domain in the same level that business people do, something like Obie’s early posts, but recently I found out that this new paradigm can help in other field, much more important I think.
Currently I’m in the second try to introduce Domain-Driven concepts into software development project. I’ve used those concepts by myself in a myriad of developments but it’s the second time I’m the guy that can tell people how they should do their work.

Domain-Driven techniques are logical and clear to most people familiar with software engineering concepts that arose in the last few decades, but unfortunately that’s not the guy you will find in standard software development shops.

If you try to explain the Repository concept to someone you’ll get what I mean. I’ve written 3 articles on mainstream Brazilian software development magazines (for both Java and .Net audiences), given lots of talks and blogged a lot about it in the last two years but every single time I present the concept I get the same questions. “So, this Repository is basically a Data Access Object (DAO), right?”

No, it’s not. The point is about raising the level of abstraction in your business rules implementation so you reach a point here the code you write has a mapping of near 1-to-1 with the actual business concepts. The main problem in this approach is that people are not familiar even with the very basic concept of a business object, every post and article I wrote have to be introduced with an explanation about why someone should avoid the procedural style that that pseudo-pattern named BO introduced.

We’re talking about senior software developers, years of experience in the field. Most of them won’t get it ever. Face it: most developers are there only to do their job the best they can. I tend to believe that people are always trying to do their best, no one wants to be fired, but they will do the least they can to achieve the target and if you think about it what they currently do makes it.

Some developers love what they do and study the better way to do things basically for fun. Others are strictly professional people and learn about the best way to do things because they don’t want to be out of the market. Others are competitive and want to be the best, doesn’t matter in what field. But most developers won’t give one hour in the weekend to study whatever new technique is arising. A book live Evan’s with hundreds of pages will not be read ever, if they need the concept they’ll look after a quick-and-dirty tutorial.

The market need these guys. We depend more and more on software and we need people to write it. the average Joe won’t get the concepts to write good software with all the tools s/he has in hands so maybe if we give them just a subset of tools things can finally become efficient.

That’s what I’ve been playing around the the last years and is my subject of research and interest right now. What if instead of 3232324 web frameworks, 31 languages, 2232 APIs for concurrent processing, aspects, domain driven design, object orientation, dynamic typing and etc we give the standard application developer just what s/he needs to do their job?

Don’t write an angry comment yet, I’m definitely not saying that a single tool, framework, language or whatever will do the job, not even for a single business domain. Software engineers, the people who read Domain Driven Design while in vacation in Rio de Janeiro will still be needed to build tools for the Domain-Specific Application developers. And this relation between engineers and app developers is exactly what people are working on right now.