CODEWITHSUNDEEP
asp.netdomain-driven-designpetapoco
RKh
RKh

Reputation: 14159

Starting with DDD pattern in business layer

I have separated the various layers (Class Library Projects) in my solution explorer like this:

I want to use PetaPoco micro-ORM and someone suggested me to add PetaPoco in the Repository layer. As suggested, I added PetaPoco to the Repository project and generated model from the database. Now the auto-generated POCOs reside in the Repository.

What I am not following is when I want to implement DDD, I want all the POCOs in the Model i.e, the Business Layer.

I added a WebForm for logging in the user in the WebUI layer. Now when DDD is to be used, do I need an interface in the Model? Where to write the Validate Login method?

Upvotes: 0

Views: 444

Answers (1)

Iulian Margarintescu
Iulian Margarintescu

Reputation: 2666

I strongly suggest you (re-)read Eric Evans book on Domain Driven Design. Also you should watch mr. Evans's videos after the book. DDD IS NOT about repositories, databases, assemblies, or user login.

There is also the possibility that DDD is not actually what you are looking for. Seems like you are looking for a layered approach with the ui on top on some entities/app-services on top of some repos on top of the database. Depending on what you are building, this might actually be all you need.

If you want to use PetaPoco and if your "orm" generates "models" from the db, then it does not make a lot of sense to separate them in different projects. The fact that the models are generated by the orm ( and the fact that they might need to be re-generated in the future ) makes them quite coupled with the orm so moving them in a separate assembly buys you nothing.

To answer your ValidateLogin question, i would suggest moving all auth related code to an infrastructure layer that is orthogonal ( vertical ) to the other layers. App users don't necessarily need to be "entities". You might also get away with having an app-service in the model layer that handles auth, but i usually found auth to be an infrastructure concern rather than a business concern.

In the end i would suggest you get familiar with the pitfalls and strong points of such architecture and then decide if it is a good fit for what you are building. On the other hand you need to be aware that DDD is not cheap to build and (as mr Evand said) you are probably not going to get it right the first few times.

Upvotes: 2

Related Questions