I've been reading a bit about DDD and trying to understand it but have a question about Ubiquitous Language. Isn't it true that in any system, regardless of whether it's DDD or some other philosophy, you should always use proper domain language in your code?
I know there are exceptions for example where the domain uses legacy language. For a contrived example, if a horse racing expert talks about the starting gate for the horses and says they are called "First gate", "Duo Gate", "Trio Gate", "Forth Gate" etc., you might want to simplify your domain language by calling them Gate1, Gate2, Gate3 and Gate4. In this case you are effectively redesigning the language in a better way (in your opinion).
But that aside, in my years of development I have never felt the urge to use anything other than domain language in my code. And so would it be right to say the rule of Ubiquitous Language is really a rule for all development and not restricted or "invented" by DDD?
I think the point Eric Evans is trying to drive home is not to let your model get out-of sync with the ubiquitous language. Let's say that at first a developer may call it First Gate and later find that the domain experts call it "Starting Gate" (I have no idea) but to make sure to go back to the code and take the effort to rename the entity and all references.
Sure it's good practice in all programming endeavors, but it is essential in DDD, which is why it gets special focus.
Related
I might have a silly question about DDD:
Are there any disadvatages of DDD generraly? I mean, besides of using it when it is not necessary, or needed. (e.g. small/not complex projets)
Thanks
It is very easy to do it wrong.
Eric Evans has said in a JavaOne presentation that DDD is best applicable when there is a lot of business domain complexity. Moreover, he explicitly states that DDD is not suitable for problems where the is substantial technical complexity but that has little business domain complexity. An example of the later is an embedded system with very simple inputs (possibly independent of the number of states it possesses) while simultaneously presenting a lot of technical complexity (in terms of getting the hardware to work.)
How we go about quantifying a lot or a little, that's an open subject. But the narrative should work as a guideline of when and where DDD is best applicable.
-- edit --
I got the video presentation through Emule, and I've never been able to find that same lecture on youtube or similar video venues.
I found this discussion of DDD in the Microsoft Application Architecture Guide to be helpful in understanding the challenges of that particular style:
As the core of the software is the
domain model, which is a direct
projection of this shared language, it
allows the team to quickly find gaps
in the software by analyzing the
language around it. The creation of a
common language is not merely an
exercise in accepting information from
the domain experts and applying it.
Quite often, communication problems
within development teams are due not
only to misunderstanding the language
of the domain, but also due to the
fact that the domain's language is
itself ambiguous. The Domain Driven
Design process holds the goal not only
of implementing the language being
used, but also improving and refining
the language of the domain. This in
turn benefits the software being
built, since the model is a direct
projection of the domain language.
In order to help maintain the model as
a pure and helpful language construct,
you must typically implement a great
deal of isolation and encapsulation
within the domain model. Consequently,
a system based on Domain Driven Design
can come at a relatively high cost.
While Domain Driven Design provides
many technical benefits, such as
maintainability, it should be applied
only to complex domains where the
model and the linguistic processes
provide clear benefits in the
communication of complex information,
and in the formulation of a common
understanding of the domain.
At an italian conference, I talked about the topic (see these slides).
DDD projects require domain experts that are often expensive to hire, since they hold valuable knowledge (read, if you don't need a domain expert, you don't need DDD).
Moreover DDD requires strong skills on the modeler side. In particular they have to be:
Humble, since they have to accept their ignorance and learn from an expert
Really skilled in OOP
Diligent, since they have to track decisions
Comunicative, since they have to explain the domain to the other devs (even through documentation)
Finding such developers can be much more expensive than expected, since you can really know that they are good at the job after some months of trials.
Martin Fowler in his "PoEA" book has a great discussion of when and what domain logic patterns to use.
For instance, simplest pattern, Transaction Script, involves no domain model.
I'm something of a programming language junkie, and examples abound...
Lisp was originally created as a practical mathematical notation for computer programs
Simula was designed for doing simulations, and gave us objects and classes
C was designed for implementing system software (specifically, the Unix operating system)
Erlang was designed with the aim of improving the development of telephony applications at Ericsson.
Languages like Perl and Ruby also, but these four gave birth to fundamental styles of computer programming, as opposed to "just" implementing an existing methodology or style of solving specific software engineering problems.
Is every new programming paradigm primarily driven by a need to solve a practical problem? Does every new programming language come about from a programmer scratching an itch?
As I plan to dedicate my life to research in new programming languages for AI, I'm wondering whether I should pursue the theory of programming intelligence directly, or attempt to solve practical problems in AI and then "discover" the paradigms to solve them.
No, most are. But you're forgetting Esoteric programming languages.
Example: http://www.dangermouse.net/esoteric/piet.html
A language that uses JPG's as code.
I think that every language is designed according to some need. That need of course can just be the language designers own desire for a more elegant language, a language he himself feels more comfortable programming in.
However, the language that are successful will very likely provide some solutions to a more general need. This need my not necesarely be evident at the time the language is designed, but for it to get recognition I think it has to be a need that is shared and gets shelved out as a general desire at some point.
There are probably a lot of languages out there that did not necessarely address a problem that is shared by many others or maybe even adresses needs that have not been wiledly realized as such.
To you concrete question: I think the best way to discover the shortcomings of current languages is to use them. Of course, the theory may help you to come up with appropriate solutions. So I'd say the best way is (as always) to have theoretical knowledge and practical experience.
You'd think nobody would invest time in inventing, refining, implementing, using and spreading a new way of doing things if "the old ways" worked just fine. And the real world, as in your examples, confirms this theory. All this still applies if we broaden the scope beyond programming paradigms. So I'd say it is safe to assume inventions are (partly) driven by a need for the thing invented.
*hits his smartass alter ego with a bat and takes over the talk*
As for the question in the last paragraph: If anyone knows whether you'll have more fun pursuing theory or solving real problems, it's you. I would choose practice any time of the day - but I'm not you. But from looking at (programming language) history I can tell that all no great (i.e. can be used to get things done) language came from theory. It is logical to assume one can't find a good tool for an application without knowing that application throughoutly from daily work.
I have no programming experience but am interested in learning a language.
So reading this section "http://wiki.freaks-unidos.net/weblogs/azul/principles-of-software#extend-your-language-to-match-your-domain" made me curious about programming a single application in 2 or more languages.
How is it actually done?
A few thoughts:
The page you linked to explains pretty clearly how it's done
If you are interested in learning a language, this is probably not the place to start
Programing a single application in two or more languages is only marginally related to the linked document.
Still, in the face of all that, I'll try to give an example of how this works by analogy.
Suppose you need to work with a group of people on some technical task--ranking chess puzzles by difficulty or testing marshmallows for contamination or something. Suppose further that one of the people on your team speaks only Japanese, another only Portuguese, and the third only Esperanto.
Being blessed with the ability to speak all of these languages fluently, your best bet is to make up an artificial language specialized to the task at hand; this is called a Domain Specific Language, or DSL. It should have all the terminology you need to talk about knights and rooks or silicate nanoparticles or whatever for the task, and not much else. Teach this to each of your team members, and then you can give them all their instructions at the same time. They can talk to each other about what they are doing, ask for help (so long as it's related to something covered by your language) as if they all spoke the same language.
That's roughly what he's talking about.
I think you may be trying to run before you can walk. The concepts in there probably require a little programming experience to start with.
The thrust of the article (and frankly poorly expressed) is that when you are programming you often encounter tasks that benefit from a declarative syntax, i.e. you should be able to express the intent of what you want to do and leave the implementation details to a library. A good example is querying a database, it's much more readable (usually) to be able to declaratively describe what you want to do and let some middleware figure out the best way to do it, SQL and Linq are 2 examples of a declarative mechanism for querying data.
This is a very interesting topic, but honestly if you have no programming experience it's probably more of a 201 subject than a 101 subject, get your basics down first.
Tomorrow i need to show small presentation about DDD approach.
It should contain 2 main points:
"What is Domain Driven Design?"
"How can we use it?"
I would be glad if i could see some ideas how to 'implement' first point of my 'presentation interface'.
Asking because I'm not making presentations everyday and i`m little bit confused.
Somewhat hard to understand whether your problem is a lack of DDD knowledge, or just how to present it.
"What is Domain Driven Design" - grab a good overview from http://www.infoq.com/minibooks/domain-driven-design-quickly
"How can we use it". You can't really just "use it". You must identify the parts of it that makes sense for your business.
You can take advantage of the big focus on understanding and modeling the business, and creating a common language in speech, code and documentation.
You can use ideas related to software architecture, like using repositories, entities and value objects.
You can take note of the principles for good design and code quality, like intention-revealing interfaces, side-effect-free functions, etc.
You can try to pass on knowledge of refactoring, and strategies relating to larger systems.
Some are low hanging fruit in concept understanding, others are hard to impose without personal interest.
Amis,
Is to translate the current slide to your needs (its in portuguese-brazil) -> Slide
Explain that DDD isnt a tech or methodology, but is more like an approach that gather various concepts, techniques and principles with focus on domain logic.
Explain about ubiquitous language, Layered architecture, Domain Patterns, and diffs about current approach and ddd approach, later on enlighten then with the benefits of using DDD over the current methods and add a conclusion on your presentation..
Hopes it helped ya.
This mind map sorted my mind.
On my reading spree, I stumbled upon something called Intentional Programming.
I understood it somewhat, but I not fully. If anyone can explain it in better detail, please do. Is it being used in any real application?
You got me started on this one...
Looks like C. Simonyi wanted to step to the next level of abstraction from High level languages. Reduce the dependency of customers on developers to make every change.. in code (cryptic for people not in development).
So he invents this new product called IP, which has a WYSIWYG type GUI editor to create a domain specific model. (i.e. IP has a GUI to create the building blocks for your app.. LISP allowed you to create the meta/building blocks but not in a way that domain experts could easily do it.)
Like the models in UML, the promise is that you can auto-generate the corresponding source code at the "push of a button". So the domain experts can tweak the model in the future and press the Bake button to deliver the next version of the app.
It seems to utilise DSLs however with the added benefit that multiple user-created DSLs can talk with each other via a built-in IP mechanism... which means the finance model and sales model can interact and reuse blocks as needed. As with DSLs, you get the benefit of code that conveys developer intent rather than appeases implementation language constraints.
The idea being to give greater control to the BA and domain experts who actually know what's needed...
Update:
Real world use looks like 'not yet'.. although Simonyi believes 'absolutely in the long term'.
Short Story: MS squished IP in favor of .Net framework, Simonyi left MS and formed his own company 'Intentional Software'.. with the contract that he could use the IP ideas but he would have to rewrite his working proto from the ground up.. (that should slow him down). It's still Work-In-Progress I think.. and being written in C# (to boot)
Sources:
Anything you can do, I can do meta by Scott Rosenberg, MIT Tech Review (2007)
To think till yesterday.. I didn't know a thing about this. Investigative reporter signing off. Going back to day job :)
It's the opposite of what happens when I come home at 2am after a pub crawl and fire up the laptop "just to check my email real quick, hon."
Then, the next day, when I peel open one eye and find my way to the bathroom at the crack of noon, I start brushing my teeth and realize, toothpaste dribbling out of my mouth, that last night I made 4 SVN commits, closed 3 bugs, and figured out how to solve the starvation problem on our distributed locking protocol. And I have no idea how the hell any of it works, anymore.
Or maybe it's what workmad3 said.
It appears to be a method of programming that allows the programmer to expand what is actually in the language to more closely follow their original intent, rather than forcing the programmers intent into the constrained syntax of the language.
It explicitly mentions LISP as a language that supports this, so I'd suggest you read up on this great language :) LISP Macros are exactly what are described in the article, allowing you to indefinitely expand the language to cover almost anything you would care to express. (A fairly common outcome of large LISP systems is that you end up with a domain specific language that is very good for writing specific applications, i.e. writing a word processor ends up with a word processor specific language).
For your last part, yes LISP (and thus Intentional Programming) is used in some projects. Paul Graham is a great proponent of LISP, and other examples of it include the original Crash Bandicoot (a game object creation system was created in LISP for this, including a LISP PlayStation compiler)
I have a slightly different understanding of Intentional Programming (as a more general term, not just what Charles Simonyi is doing). It is closely linked to fluent interfaces and can be achieved, with various degrees of difficulty, in modern Object Orientated languages.
Some of these concepts come from Domain Driven Design (in fact the term "fluent interface" has been popularised by Eric Evans, the author of "the" blue book - Domain Driven Design: Tacking Complexity in the Heart of Software).
The aim is to make business layer code readable by a non-programmer (i.e. a business person). This can be achieved by class and method names that explicitly state the intent of the operation. In my opinion, being explicit and being intentional produces highly readable and maintainable code.
Consider the two examples below that achieve the same thing - creating an order for a customer with 10% discount and adding a couple of products to it.
//C#, Normal version
Customer customer = CustomerService.Get(23);
Order order = new Order();
//What is 0.1? Need to look at Discount property to understand
order.Discount = 0.1;
order.Customer = customer;
//What's 34?
Product product = ProductService.Get(34);
//Do we really care about Order stores OrderLines?
order.OrderLines.Add(new OrderLine(product, 1));
Product product2 = ProductService.Get(54);
order.OrderLines.Add(new OrderLine(product2, 2)); //What's 2?
Order.Submit();
//C#, Fluent version
//byId is named parameter, states that this method looks up customer by Id
ICustomerForOrderCreation customer =
CustomerService.GetCustomerForOrderCreation(byId: 23);
//Explicit method to create a discount order and explicit percentage
Order order = customer.CreateDiscountOrder(10.Percent())
.WithProduct(ProductService.Get(byId: 34))
.WithProduct(ProductService.Get(byId: 54))
.WithQuantity(2); //Explicit quantity
Order.Submit();
By changing your programming style slightly, you are able to communicate your intent more clearly and reduce the amount of having to look at code elsewhere to understand what's going on.
Seems to me like yet another fad of software engineering. We've seen thousands of them already: meta programming, generative programming, visual programming, and so on. For a short time they get very fashionable, people use it everywhere, and then they invariably go back to old ways of creating software.
Why? Frederick Brooks has already answered this question over 20 years ago: there's No Single Silver Bullet to kill the werewolf...
Intentional Programming is encoding your intent, or goals. Thus it is Goal-Oriented Programming or Planning. Step up to manangement.
It's where you intend to program, you don't just accidently do it. ;)