Domain-Driven Design Fundamentals Course on Pluralsight

Steve Smith and I are excited to finally have our Domain-Driven Design Fundamentals course available on Pluralsight (http://juliel.me/PS-DDD ) . It was a long haul creating the course but we wanted it to be just right. And coordinating our schedules became tricky since we really wanted to collaborate completely on this, not just divide up the work and sew it together.

We were also grateful to have Eric Evan’s, the “father” of DDD, participate in the course by letting us interview him and use the resulting video clips where he provides thoughtful and insightful advice throughout the course.

The course has now been out for a few weeks and the reception has been great. Good ratings, great feedback in the discussions and on twitter are making us quite proud of our hard work. And it’s has been in Pluralsight’s Top 10 list (based on past 10 days viewing) in the entire library of some [I believe] 1500 courses since a few days after it was released.

If you don’t have a subscription (but really, they are only $29/month), there is a 10 day free trial on the website and I also have 30 day free trial cards I can share. Let us know what you think!

image

7 thoughts on “Domain-Driven Design Fundamentals Course on Pluralsight

  1. Absolutely love this course! Thank you for taking the time to produce this great series. I even bought a pluralsight subscription just to finish watching it :) This really shows a great real world example for how to implement DDD into my solution.

  2. Hello Julie,
    I am just beginning to take this course in Plural Sight, and I am very happy you did it. It seems very well organized and helpful. I was wondering if you could share the Solution you use in the course? It would really help to understand better the course.

  3. Excellent course, lot of new things to learn. If you still have some, please do share 30 days trail card. thanks again.

  4. Hi Julie,

    We’ve been enjoying your Pluralsight DDD Fundamentals course and have downloaded the FrontDesk sample solution for further investigation.

    Are you able to elaborate a little on the roll of the Domains, EF, and Foreign Keys? For example the Appointment entity in the VetOfficeContext does not have a foreign key constraint to Client. Has this been omitted for brevity or purity of the Domain class? We are still pretty keen on all of our solutions having referential integrity :)

    Ta,
    Grant.

    1. Hi Grant,
      We talk about FKs and/or navigation properties in the domain in Module 4 (Aggregates in the Domain). In your domain modeling, you would define your aggregate to enforce the constraints that you care about.

      WRT to EF & those same constraints defined in the database, we are not taking advantage of some of EF’s relationship magic. For example, if Client has a List property, then EF would, by convention, work out a 1:* relationship and infer the PK FK constraint in its own validation mechanism (occurs at SaveChanges) and in the database. When using DDD, depending on some of EFs relationship behavior, especially when it comes to pushing data to the database, we would have to design our model to align with EFs rules — totally against DDD concepts. Therefore we’re not relying on EF itself to define those model & DB constraints for us. However, you can still define them directly in the database. If you are using EF Code First to initialize/migrate the database schema, tehre are ways to add more instructions to the migrations to affect the underlying database. But then only the database will automatically attend to those constraints.

      HTH

Leave a Reply

Your email address will not be published. Required fields are marked *


one × 2 =

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>