I have read about creating and responsibilities of aggregates and I have doubts how to correctly implement them. Assume that we have context within there are 2 entities. One is a Company and the second one is a User. Business rules are in the Company entity that means this should become aggregate root. To the Company we can assign ony 3 users and we can not assign User when Comapny has status "blocked". User has also possibility to login using emial and password. With that in mind every action on User entity should bo invoked thru the Aggregate root and User should not have it's own Repository. How to make login action on User when we can not do it directly without Company root? We can not call User out of the aggregate. How to find User with provided email and password? Fetching all Aggregates and iterating over their Users is inefficient and I think it's not a good idea.
Thank you for help.
I think that user should belong to another BC (that manages authentication and authorization). In your Company BC, you have to get the user from the authentication and authorization BC. You have to integrate both BCs with a context mapping pattern, where authentication and authorization BC is upstream, and Company BC is downstream.
Authentication usually isn't part of a domain (in 99% of all use cases), just part of the infrastructure.
As such Users shouldn't ever appear within a bounded context. In the real business world, there are no users neither, only People, Persons, Employees, Managers or Contacts etc.
So for logging concerns you have our users with username + password which serve as authentication. These users have an id (numerical, string or guid).
Your Employee or Persons entity/aggregate (or what ever you named it depends on your domain, the exact term depends from company to company - the ubiquitous language) then only contains the data which belongs to the person (but not identificaton related information).
You can then connect employees to users (either by having the employee id be the id of the users used for login, an extra field or via a 1:1 or 1:n lookup table.
This way you can easily delete a user (the login) without deleting the Employee entity, because in real world scenarios you can't easily just delete business data (i.e. imagine deleting a user removes the recipient on every invoice or CRM data, no one would ever know this person worked there in the past).
Related
I'm creating a micro services for example one for user management i.e (roles, credentials, rights, menus etc) related and one for bank account-details, now i have a scenario to getting user roles detail and rights detail from db, is it a good practice to repeat columns of database user management db i.e.(roles, rights) in bank-account db as per requirement or duplicate data in bank-account db ?
Or no need to duplicate data in bank-account db and send a separate call to get user data first from user management db ?
please suggest a best possibility
Waqas,
You're in microservices environment. There is a well-known Domain Driven Design (DDD) with one of a key pattern of Bounded Contexts. That means you should try to avoid mixing the contexts and duplicate the user information in bank-account db (it might be inevitable some time, but I suppose not in your case).
Therefore, it's fine that you have to call user management service in order to gain the required information about your users.
I agree with #Stepan Tsybulski. Also, I suggest you reduce the need for a bounded context to depend on the other to the minimum possible. So, duplication of data is the best option here. However, you do not have to have roles and rights in the Bank Account context / DB. I'd put in the Bank Account context only what's necessary in that context: User details (such as names, birthdates, etc.) + user id.
You get the roles and rights from the session. You manage roles in the User Management context only. It's good for security and consistency, plus it's the reason for using Contexts.
There are many ways to approach a problem, but that's how I'm doing it.
I have a query that get accounts for a business unit based on a set criteria. When using one business unit, the query works find and brings back the results. Running the same code, changing only the business unit, running with a different business unit, the result come back empty.
If I run this query in HeidiSQL it works for both business units.
Another feature to this problem is in the bad business unit, a Customer Care Rep can not get the results, yet Customer Care Supervisor can. In the good business unit, both can get the results.
This leads me to think there is a problem with security. However I have compared both business units teams and roles and they match.
Is there something else, that I am overlooking that could stop a team from getting data from the database.
From: https://andrewbschultz.com/2011/08/09/business-units-bus-and-security-roles-in-microsoft-dynamics-crm-2011-solution-exports/
Without BUs, the following security configurations would be possible:
A user could have access to his own CRM records
A user could have access to all CRM records
With BUs, the following additional security
configurations are possible:
A user can have access to all records owned by users in his business
unit
A user can have access to all records owned by users in his own
and any child business units
My understanding is that if the records are owned by a user from BU1, then users in BU2 won't be able to access them until ownership is transfered to a user in BU2.
In order to have users in both BUs access the same records, you have to share all of them with at least one (or maybe all) users in BU2.
I've been reading about and playing with ASP.NET MVC lately, to figure out if it will be the new framework for an exisiting product.
The product consists of a multi-user website where the customers are created by me and added to their respective companies. Each user then has access to do some stuff, add data etc. in the scope of his own company.
How would I go about creating a structure like that in MVC?
I basically want to be the "super-admin" that can create new users, add them to companies and control their rights.
The regular users will also have different user roles (admin, user, guest) within their company.
I've got pretty much everything else set up (MVC and the Entity framework is awesome), but I just need this last layer of separation.
Any help is much appreciated.
There's really two pieces to this. The first is roles. Simply create a clear designation between roles for a company versus roles for the entire application, for example: "Admin", "CompanyAdmin", "CompanyUser", and "CompanyGuest". There, I literally mean "Company", not a placeholder for a specific company name. You should only have one set of roles applicable to all company users.
The second piece is a form of ownership authorization. Each user is assigned to a company, surely through a foreign key on your user entity. Your routes will contain some component that identifies the company being utilized, whether that be via a subdomain, or just part of the path, i.e. /FooInc/Bar/Baz. In your actions, you'll use this component to look up the company from your pesistence store and then compare that with the company the user is assigned to. If the two do not match, then you return a 403. Otherwise, you let the user proceed.
There's many ways that can be done. You could use an action filter, base controller, etc. That's largely up to you and the needs of your application. Regardless, ASP.NET MVC is very capable to handle such a thing.
I have an application where a user can be linked to several companies.
The manyToMany relationship with the company is a distinguished entity called Associate.
I'd like to give to this Associate entity the exact same role functionnality as my FOSUserBundle User entity has. Important : if a user has a role_manager for one company, it should not be given the rights to access specific features of another company he belongs to too.
Is there a clean way to do this?
I'd like to check for instance if $this->getUser->getAssociate->hasRole('ROLE_MANAGER') is true.
What if I give a role array to my entity Associate? I've read it's not secure enough? Why? What could someone do to break that security if anyway my users have to pass through FOS security login checks?
I've found an article where using a voter is suggested. But I don't want to filter routes, I really want to check the condition against the link between a user and a company, so if a voter is the solution, how would I use it?
EDIT: if a better solution not involving roles or with different logic exists, I am interested in learning about it!!
So in my case, I actually one user can actually be only linked to a maximum of 4 companies, each of a different kind defined by its category.
The official doc would suggest using ACL, defining a role for every company or store the data in the entity. cf first paragraphs of :
http://symfony.com/doc/current/cookbook/security/acl.html
I used a combination of roles and business logic. I've created roles for every type of company and since one user can only have one company per type, I just had to check for the type and the role-manager associated to the type.
See my voter here:
symfony2 call is_granted in voter : how to avoid an infinite loop?
I am in a situation in which I am supposed to model (in domain) requirement where a user can be bill admin and system admin and employee.
All the Admins can do whatever the normal user can do, but a normal user cannot do what the other roles can do. The problem is that I dont understand how I can do this by inheriting the user entity and I have read thats not a good idea, so dont want to go that way..
The Employee, System Admin and Bill Admin are different roles of a user. Any suggestions?
Update :
More Information: Given that the Employees BC and Billing BC and System BC are three different Bounded Contexts what would be the ideal way of handling the above given scenario?
It may be that you are mixing bounded concepts and the inheritance is probably not helping either :)
Typically one would have an Identity and Access Control BC. This is where we may find a User, Permission, and a Role.
Then one may have an Employee or Human Resources BC. This is where concepts such as Employee and Manager may exist.
So it may help to split these concepts.
When a new employee is registered an EmployeeRegistered event may be published by the HR BC, using a service bus, that the I & AC BC subscribes to in order to register a new user.
Hope that helps.