I'm working on my first "real" DDD application.
Currently my client does not have access to my domain layer and requests changes to the domain by issuing commands.
I then have a separate (flattened) read model for displaying information (like simple CQRS).
I'm now working on configuration, or specifically, settings that the user configures. Using a blog application as an example, the settings might be the blog title or logo.
I've developed a generic configuration builder that builds a strongly typed configuration object (e.g. BlogSettings) based on a simple key value pair collection. I'm stuck on whether these configuration objects are part of my domain. I need access to them from the client and server.
I'm considering creating a "Shared" library that contains these configuration objects. Is this the correct approach?
Finally where should the code to save such configuration settings live? An easy solution would be to put this code in my Domain.Persistence project, but then, if they are not part of the domain, should they really be there?
Thanks,
Ben
User configurable settings belong to domain if they are strongly typed and modeled based on ubiquitous language, i.e. 'BlogSettings'. The only difference between settings and other domain objects is that conceptually settings are 'domain singletons'. They don't have a life cycle like other Entities and you can only have one instance.
Generic configuration builder belongs to Persistence just like the code that is responsible for saving and reading settings.
Having found this question, I feel obliged to suggest an answer because I don't like the accepted one.
First off I don't see why this has to be a singleton.
Secondly, there is something about settings that is very important: they are usually hierarchical, and they almost always have to have the concept of defaults. Sometimes those defaults are at the item level. Other times you might prefer to replicate a whole set of defaults. Also, consider the fact that settings can use the concept of inheritance: maybe an agency has a setting, but it permits agents the ability to do their own.
Related
Fluid looks really nice if all collaborators are equal (allowed to change the same resources), but what I don't understand is how the server can prevent certain actions for certain users. As much of the logic as possible is on the client-side right? Maybe I haven't searched good enough, but I couldn't find a resource or readme that explained that part.
Example:
User A can edit the whole markdown document.
User B can edit the whole markdown document.
Both users can lock paragraphs they've created to be read-only, which only they can unlock again.
On the Fluid FAQ it states the following:
Turn-based games?
DDSes can be used to distribute state for games, including whose turn it is. It’s up to the client to enforce the rules of a game so there may be some interesting problems to solve around preventing cheating but the Fluid team has already prototyped several games.
If there is no solution for this problem, please let me know where I should start would I fix this myself. For a fun hobby project, I'm in the middle of deciding to build something new or to use fluid (which can save me a lot of work).
Right now, Fluid doesn't have the concept of Access Control, but we could include some related features as DDS features, we could implement some features as server-hosted Fluid Bot filters, and we could implement basic ACLs at the server layer as Storage ACLs.
As DDS Features
I wrote the "OwnedMap DDS" to show this concept, where users reject invalid changes from other users. This could be extended to include your "paragraph lock" concept, but I'm not sure it's rigorously secure.
I think it'd be interesting to build a library of "OwnedDDS" or DDS with filter methods on them to prevent invalid changes".
server-hosted Fluid Bot filters
Another option is to have a server side client, so a non-user client that joins the session that is not a malicious actor. This Bot could validate that changes are legitimate and then "consent" to the changes. This breaks some optimistic insert constraints, but would add more security and is more rigorously secure.
With this approach, you may still need to modify DDSs so that they're consensus based instead of optimistic, but the only consensus would be that the Bot agrees the change is valid.
Storage & Server level ACLs
You could imagine modifications to the routerlicious reference service where you need a user login to access specific containers. This is not as find grained as your request, but would clearly work!
I'm modeling my first DDD application and I caught stuck with this doubt...
In my application and infrastucture layers I have some details that need to be persisted, but, since these are not domain specific, I don't like to name it repositories. Someone can help me figure out how to name it?
Thanks.
DDD and the Repository pattern (RP) are different things, it just happens that DDD makes use of RP. This means that you can wrap everything related to persistence in repositories, they just won't be Domain Repositories. Probably in your case you'd have PaymentGatewaysRepository or smth like that.
Point is, if you wrap persistence access details into a class so that the rest of the app doesn't care about storage, you're using the repository pattern no matter how you'll name that class.
You should elaborate some more... Why isn't it modeled? Is it only configuration settings, things outside of the scope of the model? Like logs, etc? Some names come to mind: Serialization, configuration, settings, etc.
Considering your comment, configuration settings are really orthogonal to a Domain Model, but payment gateway settings may or may not be outside of the model. Id depends on the kind of application you are writing. I believe that if you are writing a payment processor, then it is a bona fide "member of your" domain model :-) You can also model generic configurations in the model... imagine that your users will have their own overriden settings.. The config "model" could weakly reference the domain model...
You can also model these specifics in another domain entirely... a reusable domain model with its own persistence, and which could be used in different domains as an add-on...
I am researching security frameworks for an ASP.NET MVC3 application that would have some pretty complex authorization rules in terms who can see data, who can create and edit it. Rules such as
- I can only see clients that are part of my company or branch.
- If I am out 15 or less days from the day the record was created and my role is of super user then only I can edit all but two fields on that record. After 16 days or more I can only edit two fields.
My initial thought was to use the Enterprise Security Block and just add customized authorizers, but after reading more about the native support for membership based security in ASP.NET, I am not so sure if Enterprise Security Block is necessary. I have not use neither of the frameworks in a real-world application so looking for some collective wisdom on the topic.
This is the problem with complex field level security. There is no real framework to help you with it, because everything is so custom. The best you can do is extract this into some kind of lookup table, and assign each field a custom identifier in the table, then have a set of columns that indicate each security level. Then, you build your business logic so that you pass in a field and conditions, and it simply responds back whether or not to allow it.
THen you have to figure out what "allow" means in your interface. Disable it? Hide it? ignore it?
I don't envy you.
You might find this semi-interesting.
http://bartreyserhove.blogspot.com/2008/12/field-level-security-using-aspnet-mvc.html
You can use Azman - Microsoft Authorization Manager and its related APIs.
It provides you with roles, actions, permissions and many more configurable options.
Azman uses AD to store most of this. It also provides options to store using local XML and/or configuration files.
You are crossing into more than just direct security concerns here but actually authorization rules AND edit rules. Your auth rules sound quite custom and I feel that you may need to process these rules in your own custom code and then include these Attributes in your own view models.
Im not aware of any frameworks that will give you this by default as these are very custom editing rules. You could call these claims and when you login go against a claims based framework such as windows identity foundations (WIF) but you will still need custom IF stmts to allow editing in your view based on properties you set in your ViewModel such as CustomerViewModel.AllowAddressEdit. Your view needs to then check this property to display DisplayFor or EditorFor. However you should also check these values on postback to ensure a user hasn't just injected values to hack your app.
You can use asp.net security for basic authentication to the site, and you can use it for basic role membership. But since these are site-wide permissions, you will need your own logic to segment users into organizational permissions.
What I've done in the past is use the asp.net membership logic to handle the basic auth stuff, but then keep another structure in your database that maps the user id's to other parameters - like the mentioned organizational level membership, or especially access rights for data-driven structures.
I'm actually surprised there aren't better solutions already built out there for handling more complext membership/permissions situations that many apps need.
Everything in Symfony2 looks pretty good however there is one issue I can't seem to find a solution too. The issue is that Symfony2's security component is limited to 30-32 roles/permissions. One of my projects, a project management/issue tracker system, is going to need more than 32 permissions. There are a number of different components of the system that need to have there own set of permissions. Just because someone has create, read, update, or delete permissions to issues does not mean they have those permissions for projects, milestones, etc... Each component is going to need its own create, read, update, and delete permission not to mention component specific permissions and there is no doubt I will reach the 30-32 roles/permission limit.
I have questioned in IRC and the mailing list with no really direction of where to go. I would prefer to be able to just added this functionality on top of the existing security component (preferably through a bundle). I am not sure how I can achieve more than 30-32 roles/permissions with symfony2's security component.
I would really prefer not to have to development my own security system w/ ACL.
as stated before in the question comments by gilden:
But this is exactly the use case for ACL. You can start using the built-in ACL system today! It's quite easy to modify/extend as well to best suit your needs.
For beginners, I think it's best to read these articles from Symfony2 official book in the following order:
Security - Including info about: Authentication and Authorization, Users & Roles, Access Control in Templates & Controllers
Access Control Lists (ACLs) - Including info about: Bootstrapping & configuration, Creating an ACL, an ACE, Checking Access & Cumulative Permissions
Advanced ACL Concepts - Including info about: Design Concepts, Database Table Structure, Scope, Pre- & Post-Authorization Decisions, Process for Reaching Authorization Decisions
There are also some interesting question here at SO.com about Symfony2 ACLs
Good luck!
I think you kind of misunderstood the acl system you can only create 32 kind of role, but by domain object. This is done using bitmasks operations on integers ( this explaining the '32' limitation as an integer is ... well you know the answer ).
So for example the permission to delete one object would be same - 'MASK_DELETE' - for a project a milestone or a ticket. So if you used the ProblematicAclManagerBundle you would just have to do :
$aclManager->addPermission($ticket, $userEntity, MaskBuilder::MASK_DELETE);
or
$aclManager->addPermission($projet, $userEntity, MaskBuilder::MASK_DELETE);
to give your user permission to delete $project or $ticket for instance. It also creates the acl entry for the domain object and the entry for the user if they are not already there. What I need to know though is if you can create different masks names for a class, or every class of a bundle ?
You will find a deeper explaination on acls here
I know this is an old post, but I just wanted to share this with anyone who has a similar answer.
The key to providing a solution is in this sentence in your question:
There are a number of different components of the system that need to have there own set of permissions.
For each of these components you could create a separate voter.
Create a class that extends AclVoter.
Override the supportsClass() method to make sure the voter will only vote for classes of the component it is meant for.
Create your own PermissionMap containing the set of permissions the component needs.
Pass the PermissionMap to the AclVoter in your services configuration.
Tag the voter as security.voter so the AccessDecisionManager will start using it.
This should get you a long way.
I also recommend going thought the code of the ACL Component, there are a lot of features that unfortunately aren't documented.
When setting up a SharePoint farm, is it technically possible to use the following URL structure?
http://myfarm/webapp1
http://myfarm/webapp2
http://myfarm/webapp3
etc.
where each URL points to a different web application on the same farm/server.
MDRoz,
Generally speaking, the answer (in a vacuum) is "no." As far as SharePoint is concerned (or rather, IIS), a hostname without any qualifying port information can be mapped to one IIS website.
Now that I've said that: there are variety of creative ways you might address this, and most are going to involve URL re-writing and remapping. A couple of ideas that come to mind:
A wonderful URL rewrite module can be obtained for IIS 7 that might work for you as-is (http://www.iis.net/extensions) ... assuming you're on Windows Server 2008, of course.
You could probably leverage Microsoft ISA Server 2006 to map incoming requests to different SharePoint web applications (IIS websites) based on path information. I don't have an ISA admin console open in front of me right now to explicitly confirm that, though.
You could develop an HttpModule that rewrites incoming URLs so that they are redirected or handled by different sites/web apps. This would ensure that redirection logic is specifically what you want.
Another link that might have some helpful tidbits comes from Todd Klindt, SharePoint MVP and all-around nice guy: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=48.
Regardless of the route you choose, I'll point out one potential sidenote and watchout: hierarchy and path depth. Generally speaking, any rewriting you do shouldn't alter a page's depth. For example, this would be okay:
myfarm/webapp1/testpage.aspx => app1.myfarm/webapp1/testpage.aspx
... but avoid doing something like this:
myfarm/webapp1/testpage.aspx => app1.myfarm/webapp1/newsite/testpage.aspx
These are fabricated examples, but I hope the point I'm trying to make is clear. In the first example, testpage.aspx is "2 levels" deep from the hostname -- and it stays that way on re-write/redirect. In the second example, it goes from 2 levels deep to 3 levels deep. Depth changes like this can lead to all sorts of insidious little problems during normal operations, as SharePoint depends on the path depth and ordering for some operations and determinations.
I hope this helps!
Can I ask why you would want to do this? You can separate out content databases this way for instance.. no need to create separate webapps.
I agree with Sean and Arjan. Sean is right to point out IIS does not support this and Arjan is right in saying that if you ahve the need for more web apps then actually create them as such, if it is just for URL sake create 1 webapp with multiple site collections each using their own content db.