"Business logic" can mean many things. Commonly, it refers to the BLL, i.e. inbetween the DAL and your presentation layer. However, "business logic" can also refer to any particular algorithm that is part of the requirements.

For example, the DAL may be expected to perform auditing on its data. Or maybe the DAL secretly keeps a historical log of all data mutations, unbeknowst to the BLL. That, too, is a form of business logic.

That is to say: validation -- does this Jedi exist? -- and consequential logic -- if not, create it -- are all responsibilities of the command(s). The logic is not encapsulated within an interface of a database context. Implementations of CQRS seems to exercise Fowler's opinion on this by having Commands and Queries that contain all the business logic while directly invoking a relatively flat and simple service or database context.

Almost with every design question in software development, there is an implicit "it depends on how complex you need it to be" caveat.

Examples are inherently intended to be simple, and therefore not throw more stuff into the mix just for the hell of it. In other words, CQRS examples will generally not bother with detailed DAL layers, as it's simply not the focus of the example.

Don't fall into the trap of building your expectations to match what you've seen in topic-specific examples, because that is a biased observation. In reality, you have multiple designs all flowing together and there is no "there can be only one" attitude, even though examples on a particular topic do tend to only showcase their particular topic.

Whether or not your DAL consists of simple methods that the BLL pieces together, or more complex methods that pre-chew everything, is a design decision you have to make.

For example, if finding out if a Jedi exists requires a lot of steps (check with the Council, check if they are a Force ghost, check for undocumented inhabitants of Tatooine with no backstory and a last name that matches a Jedi who has gone AWOL), and this Jedi-lookup logic is used in multiple places, you'll want to abstract that whole lookup process and provide a method that does it all for you. Otherwise, you are very prone to forgetting to perform all checks when you write a new command/query, or to forget updating one of the commands if the lookup logic ever changes.

That is just one prime example of why you'd want your DAL to contain more than just straightforward CRUD methods.

When you mean "business logic" as in BLL logic, then it shouldn't hit the DAL, because it inherently doesn't belong there. But that is not the same as saying that the DAL cannot contain any logic whatsoever. There could be business requirements (or good practice reasons, like above) which lead to the DAL needing to perform some specific logic as well, which you could call "the business logic of the DAL".

"Business logic" can mean many things. Commonly, it refers to the BLL, i.e. inbetween the DAL and your presentation layer. However, "business logic" can also refer to any particular algorithm that is part of the requirements.

For example, the DAL may be expected to perform auditing on its data. Or maybe the DAL secretly keeps a historical log of all data mutations, unbeknownst to the BLL. That, too, is a form of business logic, if there are business requirements that demand the feature to exist.

That is to say: validation -- does this Jedi exist? -- and consequential logic -- if not, create it -- are all responsibilities of the command(s). The logic is not encapsulated within an interface of a database context. Implementations of CQRS seems to exercise Fowler's opinion on this by having Commands and Queries that contain all the business logic while directly invoking a relatively flat and simple service or database context.

Almost with every design question in software development, there is an implicit "it depends on how complex you need it to be" caveat.

Examples are inherently intended to be simple, and therefore not throw more stuff into the mix just for the hell of it. In other words, CQRS examples will generally not bother with detailed DAL layers, as it's simply not the focus of the example.

Don't fall into the trap of building your expectations to match what you've seen in topic-specific examples, because that is a biased observation. In reality, you have multiple designs all flowing together and there is no "there can be only one" attitude, even though examples on a particular topic do tend to only showcase their particular topic.

Whether or not your DAL consists of simple methods that the BLL pieces together, or more complex methods that pre-chew everything, is a design decision you have to make. Like I said, it depends on how complex you need it to be.

For example, if finding out if a Jedi exists requires a lot of steps (check with the Council, check if they are a Force ghost, check for non-native inhabitants of Tatooine with no backstory and a last name that matches a Jedi who has gone AWOL), and this Jedi-lookup logic is used in multiple places, you'll want to abstract that whole lookup process and provide a method that does it all for you. Otherwise, you are very prone to forgetting to perform all checks when you write a new command/query, or to forget updating one of the commands if the lookup logic ever changes.

That is just one prime example of why you'd want your DAL to contain more than just straightforward CRUD methods.

When you mean "business logic" as in BLL logic, then it shouldn't hit the DAL, because it inherently doesn't belong there. But that is not the same as saying that the DAL cannot contain any logic whatsoever. There could be business requirements (or good practice reasons, like above) which lead to the DAL needing to perform some specific logic as well, which you could call "the business logic of the DAL".