CSLA.NET and DDD

[DcNathanMaroko]

Hi, I'm quite new to both Domain Driven Design and CSLA.NET. I have an existing project that implements Domain Driven Design and was wondering how well the two work together. Would it make sense to use CSLA.NET if I'm already using DDD?

Thanks.

[rockfordlhotka]

I always divide DDD into two parts: the concepts and the implementation.

I love the concepts of DDD, and the approach to working with the product owner and subject matter experts to break up the domain into sub-domains, etc. Evans did a fantastic job of describing a good process for this that is pragmatic and workable.

The implementation details can vary, and CSLA works very well with the concepts of DDD.

Keep in mind that Evans wrote his book basically at the same time as I wrote the first book on CSLA - so neither draws from the other, at least at their points of origin.

At its core, CSLA assumes that you are doing behavior-focused object-oriented design, which is basically another way to talk about DDD. Or, in my view, "the correct" way to do object-oriented design; as opposed to data-focused design, which is what a lot of folks do when they design class structures - they treat objects like database tables - yuck!

Assuming the business domain classes are designed around user scenarios, organized within domains, and so forth, you should end up with a set of types that directly support the interface (UI or API) based on collaboration between the product owner(s), subject matter experts, and the software designer(s).

A short way of saying this, is that you should end up with a business class design that directly supports the interface design that directly supports the business functionality that's being implemented.

Behind that object model you use the CSLA data portal to abstract whether there is or is not an app server, and also to abstract the persistence of your object graphs. Exactly how you implement your data access layer (DAL) is up to you, and you implement that "behind" the data portal abstraction - so your DAL is invoked based on data portal operations: create/fetch/insert/update/delete/execute.

I know DDD originally favored the use of the repository pattern, which is a fine pattern for a DAL, and people often use that pattern behind the data portal. Other folks are less formal and directly use Entity Framework, dapper, or other ORM-style technologies. Yet others use raw ADO.NET to get optimal performance, at the potential cost of developer productivity.

[DcNathanMaroko]

Thank you for the very detailed response, I'm excited to dive deeper into both