Menu
I want to start new application on ASP.NET MVC4 using different different approach like domain driven development , design patterns , dependency injection , Entity Framework as ORM etc.
Need some advice on what should be the starting point of development? Should I start with first relationships of classes or start with traditional approach? e.g there are three module.
Should I first complete with user management like domain classes then its services and then its CRUD operations in actual web application? and after that ...will start with logging (same process as mention in user management). and then in error logging as well.
So What are best practices to start development using those kind of concept or tools?
447
Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.
In addition, DDD approaches should be applied only if you are implementing complex microservices with significant business rules. Simpler responsibilities, like a CRUD service, can be managed with simpler approaches. Where to draw the boundaries is the key task when designing and defining a microservice.
Advantages of domain-driven design The most obvious advantage of DDD is that it gets everybody using the same language. When development teams use the same language as domain experts, it leads to software design that makes sense to the end user.
Code-First is mainly useful in Domain Driven Design. In the Code-First approach, you focus on the domain of your application and start creating classes for your domain entity rather than design your database first and then create the classes which match your database design.
ASP.NET MVC4 is just a presentation part of solution. With Domain-Driven approach you start with domain (usually separate library project) and then add presentation (web site, desktop application etc) and persistence (implementation of repository and uof interfaces declared in your domain).
So, you start with creating domain model (not whole, but part of that). Then in any order you create UI which uses you domain model, and implementation of repositories for persisting your domain model via Entity Framework. Well actually views should use ViewModels (otherwise your POCO domain objects will be polluted with Data Annotations attributes and other stuff). It's a controller part where you will use domain model. Also you will inject repository implementations to controllers via dependency injection.
101
I would start by looking at the business functionality requirements of the system and focus on the highest value requirements first. Implement those, filling out your business domain as you need to, based on delivering the requirements. If you follow a BDD style process, you can use unit tests to drive out the business functionality and your domain will evolve as the business requirements evolve. Each business requirement should have a UI and data access component to it so you can fill out the presentation layer and data access layer with Entity Framework as the domain evolves. Here's a couple of useful posts on BDD:
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
