I am trying to understand DDD principles. And for practice, i want to have subscription. And i am wondering in a saas application for the sake of example, the user can only access the app if he is a subscriber and has an active subscription.
Is subscription part of the domain? If yes, when dealing with an third party like Stripe Payment, should our aggregate Subscription be aware of some data from Stripe like payment_method_id for the reccurent billing?
For me, Subscription is part of the domain model since there are some business rules (authorization, access_control).
I'm a bit confused.
I recommend having a look at "Context Maps". They show the relationship between Bounded Contexts.
To answer your question: yes a Subscription is part of your domain and therefore part of some Bounded Context within your control. Stripe is a Bounded Context not within your control.
So how you model stripe in your solution depends on the relationship and strategy thereof (see context maps). Are you Conformist? Are you in need of an Anti Corruption Layer? Are you in a Customer/Supplier relationship?
A conformist approach could well be to model all stripe properties AS-IS in your domain model. It is up to your understanding of the relationship
Related
If a user has the chance of asking for his role to be changed (for example : an employee asking to be promoted to leader ). Does the action belong to the Employee or to the leader ?
You question is tagged "use-case". Int this regard, there seems to be a confusion in your question about what an actor really is. Here is what the UML specs say:
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases. Actors may represent roles played by human users, external hardware, or other systems.
If a user changes role during the interaction with the system, in the model, it's just like another actor interacts with the system. Example:
an user interacts with the system with the role of an Employee and "executes" some use-cases corresponding to the Employee actor;
this user gets promoted to a Manager.
With the new role, the user may "exectute" use-cases associated with the Manager actor.
A same user may play several roles with the system. But this does not change the model: the model is about all the users who have a given role at a given moment, regardless of the individual who performs this role.
Now in some cases, one role is a specialization of the other. This means that all the users having one role also have the other role. A typical example is if a Manager is always an Employee. In this case, you'd show the inheritance in your use-case diagram, to avoid replicating for Manager all the association of Employee with use-cases.
If your question is not about use-cases but about classes for authorisation management, then you'd need to reformulate your question. But before, have a look at the existing questions on SO, since there are many questions about class diagrams and how to assign users authorisations.
This question is really two-fold with emphasis on the most important question.
Aggregates define the consistency and transactional boundaries of a system.
Say your company provides some service through an app and you are about to add a new feature through an integration with a third party. The third party has its own API and you need to create the user in their system when they choose to use the new feature. Now, you're not a monster, so you allow users to toggle off the feature if they had previously started using it. This means you must also be able to delete the user in the third party API.
If we were to design an Aggregate for such a feature (lets say it is a subscription), where should we put the interaction with the third party API?
What if the third party we integrate with allow the users to remove themselves from their system bypassing our app completely? Now our aggregate would be out of sync.
Generally, an aggregate enforces consistency not on a system level, but over some data. The concept was introduced in the DDD blue book, and at a time where most solutions relied on traditional large-scale SQL db's, and it intended to remove responsibility for consistency from the storage layer, and into business logic. It did so because that's what consistency is: business logic. If you have to decrease stock when you sell something, this is a consistency rule, and one which should live in application code, with other business logic instead of being delegated to a stored procedure.
With that in mind, any aggregate you'd have wouldn't (indeed couldn't) enforce consistency with the outside world (it's not data you own and hold internally). However, what you could do is introduce two (or one combined) process managers:
One process manager that would enforce the policy of "when a user asks to get deleted, delete them from the external system". This would observe internal requests and call out to the 3rd party service to delete a user when the user requested to be deleted
One process manager that would enforce the policy of "when a user gets deleted from the third party service, mark them as deleted in our system too" which would do pretty much what the policy says
You may or may not have a subscription aggregate. What would determine that is if you need to enforce some consistency around data you own and are responsible for.
Suppose I am writing software for an insurance company. I use DDD and have a bounded context with entities related to the customer account, address, and related information. If a customer logs in and makes changes to these entities it is straightforward.
But as it is, there is another portal, which the internal support staff uses. Now if a customer calls in to update their account information (not a policy but phone number, address etc.). What is the best and clean way to do it?
Make a call to bounded context used by the customers (HTTP etc).
Allow making changes from the internal portal (probably modifying data across the database/schema boundaries).
Raise a domain event about changed object, and handle it on the customer side application (again this is an event related to a domain object in another context and we are not writing to database from the internal portal).
Bounded Contexts exist because they have a meaning in the domain and a reason to exist in your system. They don't exist to serve a specific type of user or a specific client application. In fact, it's most common that a Bounded Context serves multiple types of users and multiple client applications, especially in software systems with a customer-facing application and a back-office.
In your Insurance domain, both the customer and back-office users will directly interact with the CustomerManagement BC as this BC is there to serve both, not only the Customer. The same way that both the customers and back-office users will be able to see the customer's policies, their coverage, etc.
Technically, the implementation will depend on your architecture. Both client applications could talk to the same API and even share endpoints. Or you could provide an API per client, and these APIs would directly talk to the same BC (either calling the same code or by making remote calls to the same remote service).
You already answered your questions if your business allows user to directly change info about customers directly by phone call this is the case your system should allow to do it. This is what about DDD to focus on the domain and domain is business logic from your example I see the context customers management and some other contexts that use this info but if some one requires to change info about customers this is the business case and system should allow to do it!
I am trying to enforce limits in web API according to the pricing plan specification.
Example:
User subscribes to one of three plans. Each plan allows number of social media profiles to be connected for a single user. Currently limits are enforced in web api handler when user requests to connect new profile.
As more specifications needs to be met it increases complexity of api handler and it begs for abstraction. I was reading a book about Domain Driven Design and came across SPECIFICATION pattern.
Question is where specification pattern should be applied. In application layer (where api handler is) or in Domain layer?
If it belongs to domain layer should I enforce specification in Repository when adding new profile?
socialMediaProfileRepository.add(socialMediaProfile, specification);
The rule should most likely be enforced in an aggregate root, such as UserAccount. If the UserAccount tracks it's linked MediaProfile and has a PricingPlan that defines the MediaProfileLinkageSpecification it could look like:
void linkMediaProfile(userAccountId, mediaProfileData) {
userAccount = userAccountRepository.findById(userAccountId);
mediaProfile = new MediaProfile(mediaProfileData);
//throws if the related user profile linkage spec is not satisfied
userAccount.linkMediaProfile(mediaProfile);
userAccountRepository.save(userAccount);
}
This is linked to this question which seems to have asked a while back. Security implementation in a project that is adhering to basic principles of Domain driven design. let me give an example
Banking System:
Use Case: A new bank deposit is being made and requires approval as it is first deposit
a. Clerk can auto authorize if the deposit amount is <5000
b. Manager can be of two types - Bank manager / Account Manager. ONLY Account manager can authorize any accounts that have deposit >5000
My concerns are as follows (Pls correct if the concern itself is correct)
Not sure where should i build this following logic - takes care of checking whether the logged on user has authorization to do certain things taking in to account his title - (this case Account manager). Authorizing is a use case, but the security layer seems to have intimate knowledge on the domain object
In general Authorization (not authentication). I know that Role Based authentication would help, but the question is "where" - in which layer and the call flow. Should the UI layer call on some security layer or would the domain layer validate itself for all possible combinations ?
Please help. Its very confusing.
Bump to see if this gets experts notice
Cheers
Security is a cross-cutting design feature which can affect all classes, methods and properties.
From a DDD perspective you would go with specifications and roles.
Where and how those specifications get implemented comes down to your architecture. You could go with aspects, you could go with in-line calls, events, etc.
Here are some links I would check out regarding security and roles:
Security
Roles
RBAC