So we are focusing on developing a enterprise web application that utilized DDD patterns with CQRS+ES. We have a pretty good handle on that from the enterprise level. Now when we want to open up our backend services to native mobile devices using Xamarin and portable class libraries how does this come together? Do we change our domain projects in each of our bounded context to be a PCL project type? What do we do with the MVVM side of things for instance in Windows Store App, Windows Phone app? Since we are pulling from a Web API service do we pull in the PCL bounded context library or do we make a subset domain model and a separate PCL library for our native client MVVM patterns?
Right now we are leaning towards leaving the original DDD projects as class libraries and just creating a separate portable class library for our MVVM code. We will probably use file linking to link back into the domain projects to get the models so that we always have the latest set of POCO objects and any DTO objects we want to use on the client. Any one else have any thoughts or ideas on this? I really don't see a lot of discussions around this DDD+PCL combination.
I have done a lot of thinking about this and what i did to put Xamarin in my current architecture with DDD approach was:
Put your Domain Entities in a PCL project and use it to reference in all projects that you need, such as Xamarin.Forms, Xamarin.Android, Xamarin.iOS, ASP.NET, WCF, etc.
Your Domain Services can be in a normal class library that will be used for the Application layer. The application layer will be used by the Presentation projects such as ASP.NET MVC.
In the Distributed Services layer you're going to expose your services for Xamarin or other apps to communicate with your application. You can use ASP.NET Web Api or WCF with REST. This layer will also use the application layer respecting the DDD concepts.
The xamarin projects go in the presentation layer but do not use application layer. Here you will write your services for Xamarin to connect to your Distributed Services Layer through the internet. If you need offline sync you can also put that in here. Here you're going to reference your Domain Entities Project and have all your entities with their business rules.
This way you have your domain and business rules shared with all your solution and respecting DDD concepts and role separation.
Related
Sorry, if it's kind of newb question. Please, help me to correctly name the architectures I described below.
Lets take we had web-application built with Spring framework/Hibernate/Thymeleaf(or another template engine) with the code of controllers looked like:
#Controller
public class AboutController {
#GetMapping("/about")
public String aboutview (Model model) {
return "about";
}
So, this is pure MVC software design pattern, as I take.
After this we switched from Thymeleaf to ReactJS for UI. So colleagues asked me to make few REST endpoints, which was used later for drawing single React's page. To be more concrete, let's take this controllers produced a filtered list of the users and goods, which was gotten from the JPA Repository.
So, the questions are:
To which architectural pattern did we switched off instead of pure MVC in above mentioned sample?
If it wasn't HMVC (hierarchical MVC), how it supposed to be looked like in term of controllers? Is it should look like few REST-controllers, which calls each other or simultaneously being called from React?
If I have few microservices, which has endpoints being called from the one React's page (or whatsoever JS framework), how can I correctly name an architecture of the Application: "microservice app with MVC pattern?"
Architecture of a software system is about what components exists in the system, how its components arranged. Of all the components, some of them will be in the same process communicating through function calls. Some of them will be in the same computer but running in different processes. (In this case, they will talk through OS provided inter-process communication). Finally, Some of them will be running in different computers of a network. (For instance; internet) [In this case, they will talk over a network through network protocols(for instance; http) using sockets]
Spring regular MVC or Spring REST Controllers are all about how the VIEW component and the component providing access to system functionality talk to each other and what computer VIEW and component providing access to system functionality runs in.
There might might be many more components which VIEW does not know about because of the fact that VIEW is isolated from other components through back-end API. (This is true for both classic MVC and REST controllers)
For instance; classic MVC or REST controllers might be run against a database or a file and that would not effect the VIEW. There might be a KAFKA broker and that would not effect the VIEW. (In terms of functionality).
When you write your back-end using REST API, mobile applications and other applications can consume that API. Classic MVC can only be consumed by a browser.
I'm new to building APIs, I made the first one using an MVC framework: codeigniter, with chris kacerguis rest implementation.
I'm not really sure this was the best think to do because I believe maybe the framework is not that "slim" or light just to API's purposes.
I plan to do a mobile App, an admin and a website so the three can consume the Api's services.
Is it a bad idea to have the API, the website and the admin on the same project? which are the pros and cons? or the best architectural approach?
Otherwise I will have: One Codeigniter project for the API and Another Codeigniter project for website and admin
thanks
You can create folders in "controllers" folder to organize your project and use the same project/env configuration :
controllers/Home.php
controllers/api/MyApi.php
controllers/admin/Admin.php
Edit : You will share models and libraries too.
In my project I realized 2 types of controller - REST and API. Admin js gui work with REST, other world work with API. You can do it simply with silex framework, a little brother of symfony.
The purpose of building a REST API so that you only have to build one project for your business model. This allows you to construct any number of applications on any platform, only requiring you to consume the API in different ways. This essentially separates/decouples the user interface from the business logic, and vice versa.
You should create separate projects for the REST API and each UI project should also be separated projects. This allows you to change the underlying code, language and platform in any one of the projects without breaking any of the other projects as long as the API signatures remain the same.
For example, you could have a live version of your website built using Codeignitor while developing another septate project using AngularJS. When your AngularJS project is complete you would simply swap out the project on your server (or create an entirely new website or server) still allowing you to use the other if required. Additionally, you may decide that you would like to move the API onto a different platform, language or database, develope it and swap the implementation when finished causing no changes to any of your UI projects assuming you have not changed the API signatures.
We need a restful backend that provides APIs for a mobile app.
We also need a admin website to manage the restful backend.
Right now we have Sails.js as the backend framework, Vue.js as the frontend framework.
I m pretty new to MVC frameworks and I am a little bit confused how should these two frameworks interact with each other:
Should:
The frontend framework lives indepedently (maybe on a separate server), it calls api exposed by the backend framework, or
The frontend framework lives INSIDE the Sails.js, acting as the "views" for the Sails framework
I am not even 100% sure is my question a valid question, I want to know which are the popular ways and is there any pros and cons?
You can do both i.e. keep frontend framework in Sails project as well as separate independent project.
I have done both and I keep following points in mind while making this decision:
If the project is complex enough then its better to create a separate project using some scaffolding tool.
If the project is going to change frequently and evolve on its own then also its better to create a separate project.
If some one time/small view is to be made then I would prefer to keep it part of Sails project
Since you are using frontend framework for admin panel which I think
will be complex, I would recommend you to create separate project on the same server.
You can use yeoman for scaffolding. I have used it for some angular projects and it works great.
Your question is too wide for a single explanation, but the main concept is as per my understanding is data binding.
You can find a lot of free screencasts for starting from scratch, assuming you already know some JavaScript.
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.
User Management.
Logging.
Error Logging.
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?
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.
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:
BDD By Example
Introducing BDD
I’m working on a high volume transactional enterprise application(asp.net, windows app, oracle app as client) which has been designed using n-tire application and SOA architecture .The application was developed in the .NET platform utilizing C#,VB.NET, Framework 3.5 (I’m planning to upgrade to the , Framework 4.0), EF( EF in the data layer level) and WCF(WCF services in the service layer level)
Since this is the first project using EF, and having read about using EF in n-tier and SOA applications, and the features available in the EF Feature, I have the following points:
Which design pattern should I use in EF( Simple Entities, Change Set, Self-Tracking Entities and DTOs) in the data layer level
In addition Which design pattern should I use in the other tier and layer to get the best practices of EF
Thanks
"In addition Which design pattern should I use in the other tier and layer to get the best practices of EF "
I would use the saperation of concerns using IoC at the root of my design patterns. for Data Layer Abstraction purpose I would definately go for Repository patterns. There are some interesting work which you see on the web for e.g. UnitOfWork for transactions etc.
Not sure about your knowledge in Repository pattern but here's a good start.
There is also a good project on the CodePlex called Project Silk which can give you a good heads up for both the above topics among others.
All the best