Refactoring From Transaction Script to Domain-Driven Design

The Transaction Script pattern is a procedural approach to implement business logic. A use case is a series of steps in the larger procedure. To implement the use case, you call one step after the other. This is the Transaction Script. The Domain Model tries to encapsulate the business logic inside of domain entities. In this video, I will show you how to convert a Transaction Script to a Domain model pattern by moving the application logic into the Domain layer. We will apply some of the concepts from Domain-Driven Design.

Refactoring From an Anemic Domain Model To a Rich Domain Model

Join my weekly .NET newsletter:

Read my Blog here:

Chapters
0:00 Transaction Script
6:04 Refactoring into Domain Model
14:23 What is the benefit?

[antonmartyniuk]

Domain driver design in this use case absolutely rocks. Even if you don't need the whole DDD paradigm in your pretty small project or microservice: you can inject some of the DDD features here and there to make the code more maintainable.

[felipemarques]

Since you are using DDD, shouldn't it be the responsibility of the workout repository to handle the persistence of the aggregate (exercise and workout)?

Big fan from Brazil!

[kmiiloberrio-dev]

I always ask myself the same question, if you have a domain with a private constructor and some protected properties, how do you save and retrieve data from the repository?

[KsiProgramming]

Hello Milan, it is very good what you are doing, I have small remark the parameters of the primary constructor are not readonly, do not forget injectable object are invariant objects, the state of the parameters of PC can be chnaged since they are accessible every where in the class and they are not protected againt state mutation

[justinvanderleij]

Hey Milan, thanks for the great video! I was wondering how you go about unit testing this handler. Would you be mocking the Workout class?

[toviazs]

Hello Milan, I'm a recent fan of yours. I've been watching a lot of your videos to become more familiar with this concepts. I've implemented the pattern (factory pattern? not sure) that you frequently use where you add a static Create method to protect the constructor and aplly come validation. The problem i have, particularly in a class that has a lot of properties (A Store Item), is that when I try to apply this, I end up using and checking a lot of the parameters to see if they are null. In between those parameters are also some value objects, and I'm not sure if those need the null validation or not. So in summary, my Create method has a lot of if (parameter == null) throw an exception. Am I doing something wrong? Does that validation belongs somewhere else? Anywats, thanks in advance and keep up the excellent quality!❤

[sergeyt]

как всегда - структурно, эффективно и без лишней воды! супер

[innocentmwandama]

What library are you using for the return results?

[antonovxx]

What's the color theme in your Visual Studio? Looks good)

[vincentcifello]

Calling some null checks "complex business logic" is a stretch. Fowler (PEAA) specifically says to use Transaction Scripts for such cases.

Regardless, the biggest problem here is that you are leaking the persistence implementation into your Domain Model.

Using Single Table Inheritance (TPH in EFCore) can be a debatable choice although it looks to be a good solution here. However, this is purely a persistence concern that should not be present in the domain. This is the source of these otherwise superfluous null checks, not the Transaction Script vs Domain Model issue.

EF core makes it trivial to properly model this scenario and configure several different persistence options, including Single Table Inheritance.

[Forseti]

Great example, but terrible language 😅

I'm used to work in Python and its syntax is much shorter (aka do the same job with less code written).