5

Say I have a DDD application with three bounded contexts i.e. Sales, Production and Marketing.

Say I wanted to setup an administration facility. The admin facility would allow superusers' to change data in the tables that are used by: SalesRepository; ProductionRepository and MarketingRepository.

How would the Administration facility pull information from the database:

Option 1) It use the three repositories i.e. SalesRepository; ProductionRepository and MarketingRepository

Option 2) Administration would be treated as a bounded context in its own right and have its own repository. This could be a generic repository as the bounded context contains CRUD operations only i.e. there is no domain logic.

I am specifically asking if a simple Admin facility should be treated as a bounded context. I am not asking: "what is a bounded context?".

w0051977
  • 7,081
  • 1
    Possible duplicate of What, in reference to DDD, is a bounded context? – Robert Harvey Sep 01 '17 at 17:45
  • @Robert Harvey, thanks for the link. However, I have already read it. I understand what a bounded context is generally. I am asking if a simple Administration facility (CRUD only) should be treated as a bounded context in its own right. – w0051977 Sep 01 '17 at 17:53
  • A bounded context corresponds to a business domain. Is the Administration facility you speak of a business domain? Note that DDD is primarily a design philosophy, not a coding methodology. – Robert Harvey Sep 01 '17 at 18:40
  • @Robert Harvey, business users from each bounded context (domain) will use the admin facility. I am trying to figure out if the admin facility should have its own repository. Is Administration an aggregate root? – w0051977 Sep 01 '17 at 18:44
  • 1
    Is it a business domain, in the same manner that the other business domains are identified? I would suggest that it is. If not a business domain, at least a defined process. It's not necessarily just CRUD; you could have methods like GrantAccess(). – Robert Harvey Sep 01 '17 at 18:45
  • 1
    No, it is part of each business domain i.e. an admin function is required in the sales domain; also in the Production domain; also in the marketing domain etc. – w0051977 Sep 01 '17 at 18:47
  • Well, maybe it's not a bounded context, then. You're still going to need its functionality, though. – Robert Harvey Sep 01 '17 at 18:50
  • @Robert Harvey, yes I agree. Would it have its own repository or would it use the repositories of the other bounded contexts for its basic CRUD operations? – w0051977 Sep 01 '17 at 18:53
  • Which approach best meets your specific requirements? Personally, I wouldn't take dependencies to all those other repositories if a single repository would do. – Robert Harvey Sep 01 '17 at 18:58
  • I would prefer to use a generic repository for the admin facility. I just want to make sure that this is not a code smell. – w0051977 Sep 01 '17 at 19:00
  • 1
    What is a code smell? If it satisfies your specific requirements, what does the odor have to do with it? The only criteria that are relevant to your application involve things like performance, maintainability, etc., not some vague notion of code smell. – Robert Harvey Sep 01 '17 at 19:01
  • @Robert Harvey, https://en.wikipedia.org/wiki/Code_smell – w0051977 Sep 01 '17 at 19:04
  • I know what it is. I'm trying to figure out if you know what it is, in a way that is relevant to your specific project. – Robert Harvey Sep 01 '17 at 19:04
  • Let us continue this discussion in chat. – Robert Harvey Sep 01 '17 at 19:06
  • Would administrator's actions follow the same bounded context specific rules? I'm not refering to authorisation rules as the admin may do anything. – Constantin Galbenu Sep 02 '17 at 06:55
  • @Constantin Galbenu, administrators want to correct data quality mistakes. They will also deal with queries from customers; suppliers etc. – w0051977 Sep 02 '17 at 07:10
  • But will they obey the same business rules? For example, you cannot buy an item if the inventory is empty. I try to understand if you need a different application or is the same with a good authorization bounded context. – Constantin Galbenu Sep 02 '17 at 07:13
  • @Constantin Galbenu, yes they will. – w0051977 Sep 02 '17 at 07:17
  • Then it is clear. I will give an answer. – Constantin Galbenu Sep 02 '17 at 07:18

1 Answers1

1

From what I understood about your domain, you need to (create if it does not exist and) use an authorization bounded context (AuthBC) that will manage the access right to the other BCs.

If the administrators (users that have all the privileges/permissions in the system) need some new function that do not exist yet in the BCs, for example to postpone a sale, then that function will be added as usual but the access to it will be restricted to only the administrators (in fact you could restrict it to the users that have the privilege named CAN_POSTPONE_A_SALE but this depends on the internals of the AuthBC). This applies to the queries too, as they will be protected by the same AuthBC.

If you wonder how to integrate the AuthBC with the other BCs: you can do this in the Application layer, in the Application services; before executing the domain function, the service call an application service from the AuthBC and ask it if the current user can do some action identified for example by a string. Please note that this referencing to the AuthBC should not be done from an aggregate or in a domain service, only from an application service; in any domain layer you must have code that do checks specific to that domain only.

BCs=Bounded contexts

Constantin Galbenu
  • 3,292
  • Thanks. So it would have its own repository? – w0051977 Sep 02 '17 at 07:45
  • Of course. You persist the access rights of every user and/or resource. – Constantin Galbenu Sep 02 '17 at 07:47
  • Every bounded context should have its own persistence. However, you seem to manifest a lot of interest to the repositories. The most important part is identifying the bounded contexts and not the repositories. – Constantin Galbenu Sep 02 '17 at 07:50
  • I guess a generic repository would be suitable here as there is no domain logic. – w0051977 Sep 02 '17 at 07:51
  • That's up to you. Try with a generic one then refactor to a specific one if you need. Try the simples thing that works first. – Constantin Galbenu Sep 02 '17 at 07:54
  • Thanks. I am almost ready to mark your answer. What would you do with admin view models? For example, say I had a Production view model in the Production area and a Sales view model in the Sales area. Would you create duplicate view models specifically for admin? – w0051977 Sep 03 '17 at 18:19
  • @w0051977 That's not a real DDD concern, but a UI concern. I suppose that if the admin needs a lot of additional features then yes. – Constantin Galbenu Sep 04 '17 at 07:53
  • Thanks. Could you take a look at my other DDD type question here: https://softwareengineering.stackexchange.com/questions/356748/moving-role-crud-operations-from-the-controller-to-the-application-service ? – w0051977 Sep 04 '17 at 14:14
  • I see that you have answered quite a lot of CQRS questions. Could you take a look at my question here: https://stackoverflow.com/questions/46296030/why-is-getbyid-a-command-rather-than-a-query – w0051977 Sep 19 '17 at 09:18
  • @w0051977 I see that you already have a lot of answers and good folks that knows things. If you still have question after they respond to you then ask me again. – Constantin Galbenu Sep 19 '17 at 09:45
  • the other question was inspired by this one. I am trying to understand whether I am following CQRS by having a read only administration facility. – w0051977 Sep 19 '17 at 10:08