service layer with data repository

Question

Can someone explain? I'm trying to convert my wpf app mvvm into different layers (reading ddd). I have some small confusions

• Presentation Layer (WPF, WEB, API) (ok.. this I know )
• Entity Model (I know is the class that represent database table e.g customer {id,name,surname,phone} from Entity Framework

but the following confuse me

• Domain model (is the class that represent sql table columns? e.g customer {Id,Name,Surname,phone} or the class that make sense for my application e.g Customer {ID,FullName,Balance}
• Where domain model lives? in which layer (seperate dll ?, in service layer ? or in data repository dll)
• DTO (Data Transfered object) is it the same as domain model?
• Service Layer (is it a separate dll?)
• Business Layer (many times i see the word business layer, some refer it as service layer) what is it actually? is it the same? is it a different class? a different dll (layer) that has it's own responsibility apart from service layer?
• Data Repository (question is, if service layer or business layer should be implement in the same layer that repository lives)

with all the above i have make sample application trying to understand where each one goes.

STEPS I FOLLOW

1. I have sucesfully understant the data repository. a simple interface with CRUD and or complex queryies
2. I create a IService that implements and inherited from reposiroty
3. Now in wpf i have to reference the service dll, but wpf needs not only service dll but also repository dll because service layer is using it.

My Question on this is. Is It normal? shouldn't service be independent?

Should Service Layer used it's own models? and convert data repository models to service models? therefor wpf will not need reference to repository? ( but if so.. isn't duplicate work?)

Answer 1

Domain model

It depends on which pattern you want implement: rich domain model or anemic.

Some refs:

• DDD vs Anemic domain models
• Anemic domain model
• Rich vs anemic domain model

In two words:

• rich domain model - it's a model, when business logic incapsulated at your business object (model).
• anemic domain model - it's a model, when business logic implemented at service layer.

If you talks about services, it's not pure DDD, it's anemic. Fowler told that anemic is an anti-pattern, but it's used a quite often. The main problem of rich domain model, that you need a lot of experience to realise right way to implement it.
I think in your case you can use entities as domain objects.

Where domain model lives?

If you trying to implement domain model, it requires a organised structure of you solution.
Usually it contains next projects:

*.Domain - for domain objects
*.Application - for you business logic, if we talk about anemic model
*.Dto or *.Contract - for dto's or another objects that can be use at outer scope of your application (for services interactions, dto's, etc.)
*.Persistence - for data layer

Dto(Contract) is placed in another project in case reusing items implemented at them.

Where * is your project name.

DTO

Dto depends on your needs. I recommend declare dto's for each purpose, but if you don't want, you still can return domain object (but some people can say, that it's bad practice).
As I told previously you can place dto's to *.Dto or *.Contract projects

Service Layer and Business Layer

Implement at your *.Application

Data Repository

Usually you prefer to declare Data Repository interfaces at *.Domain or *.Application and implementation at *.Persistence. It allows you use interfaces and don't care about realisation.

Is it normal? shouldn't service be independent?

Best practice it's when service depends just on your *.Domain assembly.

Should Service Layer used it's own models? and convert data repository models to service models? therefor wpf will not need reference to repository? ( but if so.. isn't duplicate work?)

You services should work with domain models, and return dto's when it needs. One of general ideas of ddd, that you have common model for all operations. So it's good if you can return your domain model from repository.