Better Domain Driven Design
338df93d-2830-4335-9079-b8fcf8bb26bc
 |
Presentation |
Intermediate
Core Java
Room:
Lab 3
Timeslot:
17.09.08 14:15
Speaker: Anders Norås
One of the core principles of domain driven design is that it should
be focused on the domain and it’s logic, rather than the technology
used to implement the system. However, many projects using the domain
driven approach get tangled up in the technicalities of software
development which increases complexity, reduces velocity and hurts
both maintainability and reusability.
In this talk I will demonstrate how to employ software engineering
principles like "Don’t Repeat Yourself" (DRY), the single
responsibility principle, separation of concerns and many more to keep
attention on the model and at the same time cater for the concerns
that clutter the designs of many domain driven solutions.
After attending this talk, you should have a better understanding of
how to separate your infrastructural con- cerns from your domain
logic, build adaptable domain models that fit into many usage
scenarios and keep those models maintainable throughout the entire
project life-cycle.
Outline
- Introduction. This section is just a brief introduction to the ensuing topics. ~2 minutes.
- ΄When Patterns Become Anti-patterns‘. This section will show how we unconsciously collapse our ap- plication structures by using design patterns to increase flexibility and let rigidity creep in to our designs. ~5 minutes.
- The Strategy Pattern. The Strategy pattern enables us to select algorithms at runtime, but this comes with at the cost of forcing classes to have knowledge about the contexts in which these algorithms are used. Focusing on the implementation of a commonly used pattern drives attention to- wards how we can implement the same pattern with different means, which will be one of the themes for the rest of the talk.
- The Collapse of Application Structure. Our implementations of common design patterns causes a ΄pattern lock-in‘ that can fragment domain logic and blur out the distinction between domain and in- frastructure logic. This can hurt the maintainability of our applications. Making Roles Explicit. This section will focus on improving the design of a domain model’s internals to achieve better separation of concerns and improved flexibility and maintainability. ~15 minutes
- Our Objects Play Too Many Roles. Our domain objects, especially Aggregates, often violate sound software engineering principles. The upside of this is that it gives developers using these a better experience, the downside is that it hurts maintainability. In this section I will show how the common validation patterns we use in our models violates the single responsibility principle and eschew domain concepts.
- Refactoring to Explicit Roles. In this section I will show how to separate the concerns in the previ- ous section into domain objects and services that adhere to the single responsibility principle and makes the solution more extensible.
- Data Access is Infrastructure. This section will focus on improving the architecture of an application by clearly distinguishing between domain logic and infrastructure code. Towards the end we connect the dots by combining the lessons from this section with the ones form the previous section. ~20 minutes
- Don’t Repeat Yourself! In domain driven design we use Repositories to abstract the data access layer. Different Repositories often share the same behavior and their implementations often violate the DRY principle. In this section I will show how to refactor the repository concepts into an application’s supporting infrastructure to increase productivity, reusability and maintainability without sacrificing the flexibility of hand-rolled repositories.
- Lazy About Lazy Loading. Repositories are commonly used in conjunction with object/relational mappers to increase separation of concerns. As the real-world concerns of software development manifest themselves, these abstractions start to leak and soon our domain services get tainted with fetching strategies and similar. In this section I will show how we can combine the concepts from previous sections with Inversion of Control to keep our models clean.
- Wrap up. In this section the emphasis is on separation of concerns, the DRY-principle and the importance of keeping roles explicit. ~5 minutes
Required experience
Attendants should have at least a basic understanding of domain driven
design to get full yield. The design principles and techniques
presented are generally applicable, and can be of interest to
attendants with out experiences with domain driven design.
Expected audience
This talk is directed towards developers and architects who practice
or want to practice domain driven de- sign. It should also be of
interest to domain driven design skeptics who feel that this practice
bring too much complexity into their designs.
-
Anders NoråsAnders is a seasoned software developer and speaker. The ΄enterpriseyness‘ of EJB drove him to Microsoft .NET back in 2002, He quickly made a name for himself in the Microsoft community by using his Java-experiences to get a head start on fellow developers. In 2006 he got reacquainted with his lost love - Java, and today he is a polyglot combining the best of both worlds to build better software. Anders is the founder of the Quaere project and a contributor to a few open-source projects. He has given talks on many conferences and user group meetings and is known for talks with few slides and lots of code. Anders lives in Norway where he works as an enterprise architect (the hands-on kind) for Storebrand. You can read his blog at http://andersnoras.com.