Last session of the day is actually the one I'm looking forward to the most: How to brandish LINQ to SQL in a domain-driven design environment? I have some ideas of my own of course but I'm looking forward to stealing some from a couple of industry experts on the subject :) A little about Kim Harding. He's sold his part of Trifok and has founded a new company called Lystfisker.TV and does consultancy on the side. Jimmy Nilsson is of course the auther of a couple of DDD books.
Kim and Jimmy has two different ways of working with the product: Kim works more with the graphical designer where Jimmy starts with the code.
Avoid Anemic Domain Models which are data centered and very light on behavior. With this kind of model the behavior is usually found in transaction scripts instead of in the model itself. Queries often contain domain knowledge - they are just words without meaning in LINQ. The same query might be sprinkled many different places in the code. They have a VideoStore example they've implemented which includes a number of design patterns, associations, and aggregations.
Main focus of DDD is to work with the core of the applications and forget about distractions, don't worry about implementation details. Keep business rules separate from plumbing, e.g. keep data access code apart from business object. One of the main problems for a DDD process is that we have to deal with a relational database at some point; we need a way to bridge the gap between OO and ER and that is where LINQ to SQL comes into play. We like to start by creating the domain model and have the database take the backseat.
DDD is all about the ubiquitous language that we as developers share with the domain experts, it is developed with the domain experts in order to gain a shared idea of what we're trying to do. Many Entities are not fundamentally defined by their attributes, but rather by a thread of continuity and identity, e.g. the unique id. ValueObjects have no conceptual identity. These objects describe some characteristics of a thing, e.g. Address and Price. We can create a language from ValueObjects. An Aggregate is a cluster of objects that go together for data changes, e.g. Order-OrderLine. Repositories work as a starting point for a traversal to an entity in the middle of its life cycle; it has a collection-like interface.
Specification is used to express a business rule as a first class concept, i.e. a class. We can use it for validation, e.g are you satisfied by this validation and querying, e.g. retrieve all objects for query.
UnitOfWork encapsulates the work we're going to do and describes the context we're working in.
Add to repository
IUnitOfWork, IRepository, ISpecification<T>, LambdaSpecification<T>, IEntity<T> (T is used for key), IEntitySet<T>
Use specification as a query mechanism as well.
Good and bad about LINQ to SQL when doing DDD; Very powerful for example regarding specifications. Makes it simple to develop. Generates very nice SQL.
Don't like lazy loading requires extra attention in the domain model classes (EntitySet). Default ctor is required. Readonly keyword can't be used. Problems with value objects are not supported in LINQ to SQL which is a problem because they are extremely important in DDD. Work around exists for value objects you can add the value object to another partial class which will be joined the class generated by LINQ.
We able to work in several different ways: We can start with a tables first approach, a diagram approach, or a classes first approach. However working with the classes first doesn't seem to be the main focus of the LINQ product. Diagram approach generates a lot of code. Classes don't follow convention over configuration everything is opt-in, counter argument is that with the designer everything is generated for you. You can have LINQ generate the schema automatically but you can only create and recreate the entire database. DataLoadOptions is used to describe what should be eager loaded but it can only be defined once per entity and context. LINQ to SQL was not designed for DDD but more for when you have an existing database. Leads to Anemic Domain Model because you get in the mode of scattering queries all over the place.
In conclusion LINQ to SQL looks like a good product and a step in the right direction but will be an eye opener for many developers doing DDD.
Streamlined Object Modeling book recommended.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.