Intro
Overall Presentation Goal
Speaker's Qualifications
DDD can save legacy codebase
Agenda
Agenda - where are we
Domain Driven Design
Example: Night at a Bar, functions
Non-DDD solution
DDD solution
DDD advantages
DDD - when and where
Exercise: DDD good idea?
DDD Litterature
DDD on Green Field Projects
DDD with Existing Code Base
Domain Logical Value Objects
Agenda - where are we
Values
Value Objects
General Domain Value Objects
Domain Logical Value Object - String Wrap Style
So What?
Ex: CRM-application
Adding Customer with Phone Number
Phone Number = Strings all the way
Agenda - where are we
Agenda - where are we
Service API Clarity
Phone Number - annotated data
Service API - Summary
Agenda - where are we
In-Data Validation and Error Handling
Format Control Finds a Home
Format control ... even more ridiculous
DLVOs should be well-formed
Taming "213e%s3#4"
Domain Logical Value Object - String Wrap Style - Safe Version
Format control ... yet more ridiculous
Format control ... totally ridiculous
Format control ... getting better
Format control ... getting good
Input-validation where it Belongs
Input from Database
In-Data Validation and Error Handling - Summary
Agenda - where are we
Business Logic Tier Code
Better focus: Irrelevant functionality moved out
Bad Focus: Detail Cluttering
Bad Focus: Detail Clutter - not better
Extract simple functions to method
Migrate simple functions to DLVO
Abstraction, my dear Watson
Business Logic Tier Code - Summary
Agenda - where are we
Testability
Case: phone number is String
Case: phone number is PhoneNumber
Testability - Summary
Analysis - Summary
Agenda - where are we
Candidates for DLVO
Composed objects
Advanced computations
Really composed DLVOs
Note on Tiers and Packages
Evaluation DLVO
DLVO as DDDoor Opener
My Boss' Slide
Agenda - where are we
Recap - Overall Presentation Goal
Recap - DDD can save legacy codebase
Summary
Anything worth remembering?
Code Should Mean Something
The technique of domain logical value-objects (DLVO) is a method for domain-driven programming that stays close to the code. It takes the 'middle road' by identifying domain concepts that are more than 'just data' (e g strings and integers), but still not 'big enough' to qualify as long lived objects with a unique identity (e g customers and orders).
Examples from a CRM application could include phone numbers, credit classifications, email addresses, and contact intervals. By explicitly spelling these out in the design, they provide an effective way of gathering validation and other operations for reuse. As an effect it simplifies a lot of other code, which was earlier uttered with these kinds of operations.
The major advantage of using DLVOs is that it can start being applied immediately. It does neither take structural changes of the overall structure, nor craves a heavy round of preparing refactorings. So, it can be applied with a very small initial effort. In that way, it is possible to very fast start reaping some of the fruits of the domain driven approach, e g more structured in-data validation, more expressive service-APIs and clearer code in the business logic (often EJBs or similar).
I this session we present domain-logical value objects, and how you write and use them in practice. The concrete code examples are in Java, but the ideas and techniques can just as well be applied to code written in C++/C, VB or Ruby.
Dan Bergh Johnsson is programmer, system architect and consultant at Omegapoint AB, Sweden. Since the time as Assisting Teacher at the computing science department at Uppsala University, Dan has propagated for Code that Mean Something (as opposed to just doing it). Nowadays, this is reflected as an interest for high-quality system development, with unit-testing, DDD and agile methods as some specialties.
