I've read a lot of topics about making ef core + ddd working together but they are only show an example where we have only one microservice. I stuck with solution about putting EF Core + DDD right where it's more than one. For example we have 1 database and 2 microservices (identity, schedule). In every service we have to keep own bounded context. Identity service only working with User, Role, ... tables... In opposite, schedule service working with User, Appointment, etc. Also, when we design a domain model we only using properties we need. So, in Appointment service for User entity I only need to use for example Id, NameDetails, Address, ContactInfo when in identity service I use Email, Password, etc. The question is: Should I use the different db context for each microservice? If yes, how I should handle migrations in that case?
Using one database for two or more microservices is a contradiction in itself. A microservice is supposed to be autonomous, meaning it should not share the same database with a different microservice.
If you need to reference a user-id for instance in two services, you would only store this id, whether it's an integer, a string or any other kind of key.
Your second database will not be able to validate the existence of that foreign key, since it doesn't know about the table where the Users are stored in.
You would want to create a single db-context for each service, that has it's own migrations and it's own database, when you really want to use microservices.
If you still want to use the same database to do that, you can create many DbContexts that actually point to the same database, but only define a set of entities.
In general there are different levels of domain-driven-design. You can do domain-driven-design without microservices and even without distributed systems. Keywords like Aggregates, Commands and Events, Distributed Systems are all part of domain-driven-design.
Some resources to read about domain-driven-design
https://stackoverflow.com/a/1222488/5397642
https://martinfowler.com/bliki/DDD_Aggregate.html
https://medium.com/withbetterco/using-aggregates-and-factories-in-domain-driven-design-34e0dff220c3
https://dev.to/designpuddle/apps--microservices--what-you-need-to-know-autonomy-and-the-challenges-you-will-face-39e1
I think that in this particular case User in Identity service isn't the same as User in Appointment service. I would make new Entity called, for example Person(with attributes such as NameDetails, Address, ContactInfo, DateOfBirth etc..) , in Appointment service and save it in separate database for that service (2 databases 2 services).
Related
I have a shared Database for a Multi-Tenant WebApplication, that uses Entity Framework Core. The Tenants have their own Tenant Table and every model has a Tenant ID.
By Design it is not possible to access the data of another Tenant because I have Query Filters and the code in the controllers always checks TenantId.
But I would like to encrypt the data of each Tenant or at least the most sensetive data with a different key or purpose string.
I implemented it for one model with the Protection API.
It would be a lot of work though to implement it for every model, because I have to call protect and unprotect after every Database call in the controller.
I am using MariaDB as my Database. Does somebody know if it is possible to let MariaDB do the encrypting? I know you can encrypt the data at rest, but is it also possible to encrypt different rows identified by TenantId with a different key?
What is the best way to store your user information per client? I have several applications which all use the same IdentityServer instance for authenticating. ASP.NET Identity shows how to extend a user by inheriting from IdentityUser.
public class CustomUser : IdentityUser
{
public Int32 CompanyId { get; set; }
}
However, I have applications that have mutually exclusive user information(eg. other applications don't need CompanyId and have properties the the CustomUser's application doesn't need.).
One way would just to create a single type containing all the properties for both. There could be a problem when a property overlaps where both applications need CompanyIds for different companies, not to mention that every column would always be queried every time a lookup was done, so this doesn't seem right. The other option is that I could just create a UserData table in the client applications and query from there as needed which is probably what I have to do since I don't think there is a better option.
If anyone knows a better way let me know.
If would be perfect if UserManager allowed for registration with multiple custom user types and you could get different subsets of data based your choice while each query was optimized for only the data it needed. Then you could put an SQL index per type and maybe even user TPH in entity framework to organize the information.
Unless diving too deep into too app-specific stuff, it looks like a normal user profile.It contains a number of claims describing the user. Let's consider only user specific, not application specific. For instance there are age, country, postal address, gender, whatever. And some apps need only age and country to restrict some content, while the others need postal address or email.Authorization request can contain a set of claims and scops to fulfill these requirements.All above is just about user information, not access rules, and all above is already in the protocol.
Regarding more app-specific... why not to store such stuff more close to the apps and link by user id...
While writing a solution from scratch based on microservice approach (more specifically it is Azure Service Fabric) I came to an idea of splitting the user Identity (which is login credentials, claims, etc.) and user profile (which may contain some social info like avatar, links to social networks, birthday, etc.).
For the identity, I'm going to use IdentityServer4 (stateless ASP.Net Core) and for storing all these data I'm thinking of an Entity Framework + SQL. The profile will be managed and stored on different microservice (stateless as well) with a connection to Cosmos DB (via Mongo DB API), thus making it a NoSQL storage.
Are there any disadvantages of such an approach I'm not aware of?
You're conflating a bunch of things here. First, you have your actual "user" entity persisted to the database. There is no good reason to split a "profile" from this, as it's all just data about the user. If you're using Identity to manage users, roles and such, it was designed to be extensible from the ground up, meaning put user data on the user entity. A separate profile entity only serves to necessitate an join for no purpose.
At a higher level, once the user has been authenticated (via Identity Server), you have a principal. That principal is basically just a set of claims tied to a particular "identity" (i.e. the authenticated user). The claims come from multiple places, it could be data on the user record, roles, or even third-party claims such as when an external login account is utilized. Where the claims come from is mostly inconsequential.
Long and short, there's no reason for a separate profile entity and especially no reason for an entirely different service to work with profiles. That profile service would inevitably have to utilize a user service, so there's a hard dependency between the two: a clear sign that it's no a true separate service. In fact, this only makes the rest of your app that much more complicated as then you're having to work with both a user service and profile service depending on what piece of the user you're after.
We have a large multi tenant business application and we want to know how Entity Framework and Authentication will fit in this design; i mean i need samples on how to use Entity Framework in this design and how authentication will be done; i see Dynamics Crm and sharepoint use Configuration(Master) Database and different databases for each tenant; how the users will be authenticated and saved;when i investigate dynamics crm configuration database, i see it contains users table; also, the tenant database contains Users table and i don't know the difference
Your question is broad and may require a lot of detail to go into. I would like to give you a simple overview.
The Entity Framework & OWIN Middleware's are one way of easing in the development effort. You choose EF when you ONLY have a object model that is similar to that of your database.
The advent of OWIN middlewares help you to easily integrate with a wide variety of authentication mechanism like Google, Facebook, Azure Active Directory etc...
Additionally, in addition to using OWIN, you will still require to build a logic around the user and tenant management systems. There will be a tenant table that contains the metadata about your tenant's [customer's].
There will be a user table that will contain your user's against tenant's. Here, each row can be identified against a tenant using tenant identifier or you can opt to use a separate table for each tenant.
The single database model is the one which is shared by all the tenant's and is belonging to the Level 4 of Multi-tenancy.
You should decide based your business specific use case whether you need to support a shared database or a dedicated database per tenant.
With OWIN, I have also written middlewares that can talk to any OAuth2 enabled IDP and get back the user into the system. It is upto the business usecases which drive the level of customization and depth of integration required and the technologies just help us achieve the same.
Please share some more specific questions or your views to discuss further
(ASP.NET MVC 4.5) Imagine you have a model for a bank or a company that has IDs that are sensitive information such as an account number or some other personally identifying information. What is the best way, or at the least what are some strategies, to route the edit/display actions without placing this information in the URL.
Obviously this would be bad:
https://goliath-natinal.com/Accounts/Edit/954321
if 954321 is your bank account number.
I imagine one way of doing this would be to add a GUID to each account that acts a a surrogate key. But I'm very curious to know if there are any possibilities for doing something if you cannot change the database at all.
Just throwing some ideas out here...
You could encrypt your identifier using Rijndael or some other type of encryption. You could salt and hash it based on other identifying fields related to the account. You could do that on the fly. You'd take a processing hit though.
If you're using a memcache or azure caching you could create a map of accounts to guids and let that just sit in the cache. If allowed, in the DB you could create a separate mapping table that maps the account to a new guid.
Can you give more info on the full restrictions? I.E. Is the table restricted from change, or the whole DB? Could you create a new DB?