Your current filters are…
by Eric Evans
Large information systems need a domain model. Development teams know this, yet they often end up with little more than data schemas which do not deliver on the productivity promises for object design. This tutorial delves into how a team, developers and domain experts together, can engage in progressively deeper exploration of their problem domain while making that understanding tangible as a practical software design. This model is not just a diagram or an analysis artifact. It provides the very foundation of the design, the driving force of analysis, even the basis of the language spoken on the project.The tutorial will focus on three topics: The conscious use of language on the project to refine and communicate models and strengthen the connection with the implementation. A subtly different style of refactoring aimed at deepening model insight, in addition to making technical improvements to the code. A brief look at strategic design, which is crucial to larger projects.
Eric Evans, Domain Language
by Eric Evans
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.
Eric Evans, Domain Language
by Dan Haywood
Apache Isis (incubating) is a framework (*) that allows you to develop fully-blown applications simply from a pojo-based domain object model. Using convention and annotations the framework builds a meta-model of the domain objects and the rest of the framework uses this to apply security, transfer objects over the wire and ? most significantly ? to render them in an object-oriented UI. In this talk Dan Haywood ? co-project lead for the framework and author of a recent book on DDD - will explain how Isis' programming model supports a domain-driven approach by enforcing a rigorously layered architecture and providing the key building blocks needed to build domain-driven applications. He'll also demonstrate how the domain model can be deployed with different presentation layers, either on the web (there are several web viewer technologies supported) or as client/server; and be deployed with different persistence technologies (RDBMS through to NoSQL). (*) Prior to being accepted into the Apache Incubator, Isis was the original Naked Objects Framework, along with several sister projects.
Dan Haywood, Haywood Associates
Apart from being hard to say, ubiquitous language seem to be the hardest part of Domain Driven Design to grasp. We dive into what is meant with a "language" in this context, and how it is linked to domain modeling. Of course there will be philosophy, but the focus will be on how to make the practice valuable to our development effort. Therefore we will talk about practical issues, like who will need to be involved, how to handle synonyms, and discuss traps that can trip the effort.
Dan Bergh Johnsson, Omegapoint
Applications have a tendency of becoming harder and harder to maintain over time. That affects the cost as well as the possibility of incomes thanks to meeting new business opportunities. For some applications, it’s considered valuable to give them a remake to make them more maintainable and such remakes have a tendency of affecting the overall architecture. In my experience, DDD is often used for describing the new target architecture, but it’s also a very infuential and valuable tool and philosophy for taking on such a task.In this presentation we have distilled a set of common key possibilities in such situations, both how they can be achieved and what benefit they will give. You will also learn what to watch out for from our lessons learned.
Jimmy Nilsson, factor10
Domain Driven Design has become a ubiquitous approach to tackle complex problem domains and build a rich object model. A crucial DDD concept to access entities is the repository. Besides that, JPA has become the standard and widely accepted way of object persistence in the Java world.
This talk starts with a brief analysis of a plain JPA based repository implementation and outline pain points esp. regarding the domain driven approach (lack of abstraction, tediousness of executing queries, pagination and so on). The main part of the talk then takes a step by step walkthrough the issues and see how the Spring Data JPA project (formerly know as Hades) can help solving these issues.
The presentation is 80% hands on - less slides, more code :)
Infomal Domain Driven Design unconference.
Dan Bergh Johnsson,
14th–16th February 2011