|
|
|
<<< Previous speaker
|
next speaker >>>
|
Eric Evans, Mr. Domain-Driven Design
Eric Evans is a specialist in domain modeling and design in large business systems. Since the early 1990s, he has worked on many projects developing large business systems with objects and has been deeply involved in applying Agile processes on real projects.
Out of this range of experiences emerged the synthesis of principles and techniques shared in the book "Domain-Driven Design," Addison-Wesley 2003.
Eric now leads Domain Language, Inc., a consulting group which coaches and trains teams to make their development more productive and relevant through effective application of domain modeling and design.
|
Presentation: "What will not change by 2015"
Time:
Thursday 15:00 - 16:00
Location:
Fleming Room
Abstract:
Over the next five years, a hundred new frameworks and processes will spin around and distract us. One or two of these will catch on and begin to influence our work, but most of the technologies that we practitioners will use five years from now are already in in wide use today and will have undergone only incremental refinements. Furthermore, today's design principles and the design constraints imposed by our technologies will pertain to the decedents of those technologies far beyond 2015. Five years is really not so long, if you look beyond the details of the latest API.
Presentation: "Folding Design into an Agile Process"
Time:
Thursday 16:30 - 17:30
Location:
Henry Moore Room
Abstract: After a decade of heavy process, the Agile revolution of the late '90s
threw off the dead hand of big upfront design. The bloody purge that
followed was needed!
There were unintended consequences. Too many teams interpret "Agile" as
a permit to not think about design. But if they have ambitious goals,
Agile teams need more than standup meetings and iterations. Many teams
get off to a quick start, building lots of features in early iterations,
but end up with a "Big Ball of Mud". Without clear and well-structured
code, they cannot sustain their pace and also put themselves at risk of,
one day, encountering a critical feature they simply cannot deliver.
Without the common understanding between developers and stakeholders
that is forged in domain analysis, one of the greatest benefits of
iteration, the deepening communication about what the software should do
and how it should do it, is never realized.
We must not return to the "Analysis Paralysis" that we used to endure
(and that many teams still do), but interpreting "Do the Simplest Thing"
as "Do the Easiest Thing" doesn't work either.
This talk will consider ways of incorporating modeling and design into
the iterative process in a lightweight way that increases communication
with stakeholders and decreases the likelihood of painting ourselves
into corners, without returning to the dead-hand of the analysis phase.
As a concrete example of how such techniques can be incorporated into
the Agile framework, we'll have an overview of a simple process Domain
Language has used with its clients for the last six years.
The right kind of modeling and design, far from bogging down a project,
leads to a livelier and more sustainable development pace.
|
 |
| |
