namespace DomainLayer {
public class Customer {
…
public interface CustomerRepository {
Customer FindCustomerById(int id);
…
}
…
}

namespace PersistenceLayer {
public class CustomerRepositoryImplementedWithNHibernate: DomainLayer.CustomerRepository {
public DomainLayer.Customer FindCustomerById(int id) {

This is a conflict with what a lot of people think, including Eric Evans as I understand, considering his statement at page 73 in DDD book about the infrastructure layer:
“Being below the domain layer, it should have no specific knowledge of the domain it is serving”

So, what is the appropriate conclusion here…?
(the way I understand it, Eric does not seem to apply the Dependency Inversion Principle for repository implementations…)

Yeah that’s what I meant – implementations of repositories are typically infrastructure.

But ultimately, it doesn’t matter what projects the classes reside in, it matters what uses what. You could put it all in one project if you like (reduces compile time). Logical != physical layering.

Hmm, you start the sentence by saying repositories are not part of the infrastructure (without specifying whether you mean the interface) and then you finish with the word “are” without me being quite sure whether that word refers back to domain or infrastructure, so I am not sure whether you agree or not…

Is this what you mean ?:
Repository INTERFACES are not infrastructure.
Repository INTERFACES are part of the domain. IMPLEMENTATIONS of repositories are part of the infrastructure.

Repositories aren’t infrastructure, they’re part of the domain. _Implementations_ of repositories are. Keep in mind the difference between implementations and abstractions, implementation can come from Kalamazoo, but no one knows about it!

using DomainLayer;
namespace PersistenceLayer {
public class CustomerRepositoryImplementedWithNHibernate: CustomerRepository {
public Customer FindCustomerById(int id) {
…

namespace DomainLayer {
public interface CustomerRepository {
Customer FindCustomerById(int id);
}
}

namespace DomainLayer {
public class Customer {
…

namespace DomainLayer {
public class CustomerService {
public CustomerRepository CustomerRepository { set; get; }
public void “someMethod()” {
…
Customer customer = CustomerRepository.FindCustomerById(123);
…

The fundamental question here is whether this kind of dependency should be allowed:
PersistenceLayer.CustomerRepositoryImplementedWithNHibernate inherits e.g. depends on DomainLayer.CustomerRepository
(the way I comprehend DIP, the answer should be yes, even tough most people would probably spontaneously think that the dependency should be inversed)

Strategy means I can swap out implementations of an algorithm. In this case, I have a “US tax strategy” and a “UK tax strategy”, each of which calculate tax very differently. But the order processor calculates total the same each time.

I would make a new order processor for each order. Object creation is very cheap, so I’m not worried about keeping it around.

This code came from a legacy project where the “OrderProcessor” did way more than it should have. Typically I would move the “CalculateTotal” method to a class that better encapsulates this responsibility.

Your orderprocessor takes IDiscountCalculator and a ITaxStrategy as input, but this must be wrong, because of the Strategy for taxes lies in each order and you can’t use the same Strategy for both “US” and “UK” orders. Or do you want to make a new OrderProsessor for each order? This seems somewhat troublesome to me.