Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Niclas Nilsson on Nov 08, 2007
Why bother with models?
Many development teams undertake modeling, yet they often end up with little more than a data schema which does not deliver on the productivity promises for object design. What does it take to make a domain model truly pull its weight and positively transform a project? To do that we need a model that is not just a diagram or an analysis artifact, but that provides the very foundation of the design, the driving force of analysis, even the basis of the language spoken on the project.
In this talk, Eric Evans outlines some of the foundations of domain-driven design:
View the 60-minute InfoQ exclusive presentation Domain-Driven Design - Putting Models to Work to learn how to tackle complexity in software. Remember - the most critical complexity of most software projects is understanding the business domain itself.
Technical Debt and Design Death
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Agile Development: A Manager's Roadmap for Success
Architectures Behind Facebook, Skype, Sky.com, Bwin, League of Legends @ QConLondon
I do not see any control for pause/forward/play recorded presentation. It completed Eric's first part, but it is not playing the 2nd part of the talk. Do i need to wait for 30 minutes for the break between 2st part and 2nd part?
well, i found the controls by mouse over the video,
so i found the end of the talk, i guess that the 2nd part of talk is not posted yet. am I right?
this is a great talk i recommend for everyone. Very well put and clearly explained concepts
Yes, it seems to be based on true experience.
I once used other names in this domain, like Trip, TripEvent(Stops), TripSections(Legs) etc, a bit abstract perhaps, but generic. Downside with "generic names" is that it doesn't tend to sound very much like the "domain language", which is important for communicating core concepts with the domain experts, upside with generic names is (for the designer) that the emerging model "invites" to discovering generic patterns and "meta solutions" (a kind of a "the trees don't obscure the forest effect" if undressing the names of domain specific implementations). This in turn increases "insights" in the problem domain.
And yes, try to get as deep into the problem domain as possible by discussing many and all aspects with domain experts. Don't stop at the first bright idea. I like that.
But, OTOH, do NOT assume that the domain experts _fully_ understand the principles involved!, instead DO assume that they know (the best) how to do the job the way they currently do it (which is not exactly the same...).
What I am saying is that a thorough analysis in the pre-design stage is an unique occasion also for the domain experts (usually the end customer) to learn to even better understand the problem domain(s) at hand, and from that follows a unique opportunity to potentially *improve* the business concept(s). Well, that's my experience anyway.
It would be really interesting to hear also the other half of the lecture, hopefully the second part will also be uploaded?
Hi Yale
Yes you're right. the second part of the talk will be published soon:)
Hi,
Can the video also be downloaded somewhere? My connection fails sometimes and the player wants to restart and I am not able to seek to the point where the player stopped the last time.
Unfortunately not, however we are working on a fix but it may not be around for another couple of months.
Hi Ivo , you should try OrbitDownloader. Its free and can download any types of video :)
A very good talk. Despite Evans' moments of awkwardness he gave a coherent and well expressed presentation with a thought-out example.
As a practitioner the new and exciting bit was at the end: many models can work to our advantage. Often I will consider 'the context' of a system first, define the basics of 'it' and move on. Maybe, next time I will spare some thought for the many contexts and workout a framework for each of them. I can't wait to see how to make it work, in part two... how/where will it be advertised? Will there be a link from this presentation?
>> Despite Evans' moments of awkwardness
Wow this really was an idiotic claim!
What if Mr. Evans was only thinking very deep inbetween, trying to increase value by trying to avoid confusing you by introducing too much complexity too early?
He's actually doing very good. He's allowing things to sink in.
Would you know exactly why his very humble and pleasant performance sometimes makes a short brake for a moment of deeper reflexion?
This is what designer's do. They stop and think where other ruch ahead and causes,um... "all sorts".
Disregard this stupid comment.
// Rolf Lampa, Sweden.
>> Disregard this stupid comment.
Well... this comment doesn't look very clever either...
It should of course have read:
"Disregard the quoted stupid (and mean) comment, by Corin Lawson"
Great how different the interpretation of "soon" can be.
Part two is now online on InfoQ: www.infoq.com/presentations/strategic-design-evans
Part two is now online on InfoQ: www.infoq.com/presentations/strategic-design-evans
Thanks. This second part was very good as well. What's really worth considering in any enterprise system is the approach to separate a system into :
- Core Domain(s)
- Sub Domains (generic or supporting dittos)
Very good talk and recommendations, with example of how to people tend to put too much effort into the wrong (sub) domains and so end up with a crappy designed Core Domain.
Eric demonstrates his experience - and matureness - as a designer of "real world business systems" when he points out that business systems actually has to incorporate ALSO messy and chaotic parts (for example for varying types and quality of in-data to the system) since this is an essential part of supporting (solving) the REAL business problems/situations. But - and here comes the point - although "messy parts" are unavoidable, make sure to keep those messy parts (domains) out of the "clean" and well designed Core Domain(s)!
No surprise, very good talk again! I look forward to seeing also the third (last?) part. :)
// Rolf Lampa
PS: Btw, was this video recorded in Sweden? (I think I saw the text "musikhuset" (music house) on that blue sign).
PS: Btw, was this video recorded in Sweden? (I think I saw the text "musikhuset" (music house) on that blue sign).
In Denmark actually, at the JAOO conference.
Kind regards
Niclas
where can i download the slides...?
please...
Thank you so much...
unfortunately Eric is totally wrong concerning the size of countries on his map since it is no map that projects the size of a country or contintent correctly
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
18 comments
Watch Thread Reply