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);
}
Related
I am very new to domain driven design and having a hard time understanding one thing which I will ask towards the end of this post.
Following are the facts that I am aware of, about DDD.
External REST call to get data for performing domain/business logic should happen in application layer.
Factories are a part of domain layer and should be used for creating domain objects.
Now, I am trying to devise a REST micro service. The payload of the POST service that I am designing, let's call it SearchRequest, is something that I am considering a part of my domain. SearchResponse, which is the response of my micro service's REST api is again a part of the domain.
My first question is, should SearchRequest & SearchResponse be a part of my domain model?
Also, for preparing SearchResponse I need to make an external API call, the request payload to which is present in a third-party jar. I need to write a complex logic to prepare the request payload for external api using data from SearchRequest.
Should the request payload for external API be a part of the domain? If yes, then I can have a factory in the domain layer to prepare the request payload. If not, then in which layer should I have the logic to create the same. Can I use factory in the application layer for creating objects that are not a part of the domain.
My first question is, should SearchRequest & SearchResponse be a part of my domain model?
Ideally, no. Request and response are application layer constructs. Application layer is meant to serve various use cases of a domain; it is not the domain itself.
Should the request payload for external API be a part of the domain? If yes, then I can have a factory in the domain layer to prepare the request payload.
Firstly, the external API payload is not part of your domain; it belongs to a different bounded context, expressed in its own ubiquitous language. A little background before coming to the exact potential solution: Two bounded contexts must not mingle freely for the obvious reason that the same concept may have different meanings in different bounded contexts. Communication between two domains must happen through an anti-corruption layer (ACL) that maps the external bounded contexts into your own and vice versa.
As Vaughn Vernon suggests in his book, the ACL may be implemented either as a domain service or even a repository, both belonging to the domain layer. Assuming you go with the domain service, pass the necessary fields from SearchRequest to a domain service method that makes the external call. The method hides the external service request construction logic and also the external service response mapping to your domain objects. The domain service contains references to objects (in your case the types defined in your third-party JAR) necessary to construct the external request but its clients remain ignorant about the external service's domain (bounded context).
The main rule here, that the domain model must not depend on anything. If it depends on something, then you must decouple it with interfaces or events.
I think the answer depends on how much these external API calls creep into your domain model.
a.) If it is just one call, then you can define an infrastructure service interface for the external API call and inject the infrastructure service into a domain service and call that domain service from your domain.
b.) If you use several different calls, then you can have multiple domain services and multiple infrastructure services.
c.) If you go real complex, then you can define repositories, entities, etc. too, maybe even a separate bounded context and end up with a complete anti corruption layer.
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
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!
currently I develop a backend based on the microservice architecture.
Unfortunately, I have a problem how to realize the authorization.
So let me explaine my system - there are the following services:
OAuth 2.0 Service (issuing JWT)
Group Service
Some Ressource Services (e.g. ToDos Service)
Every user is in one or many groups.
Each resource (like a ToDo list) also belongs to a group.
That means if some user creates a todo list, that list gets stored in the name of the group.
Szenario:
User A is in group A
User B is in group A and B
User C is in group C
User A creats a ToDo list in group A.
User B modifies this ToDo list (he is allowed to do this since he is also in group A)
User C also tries to modify this ToDo list, but he shouldn't allowed to do this since he is only in group C.
Has any body a great idea how I could realize this in a microservice architecture and keep the dependencies between the services on a minimum?
Certainly, I could ask on every request the Group Service if the user is in the group to which the resource belongs to. But so I get a really hard dependency between the Resource Services and the existence of a Group Service - I like to avoid this dependency.
Another option would be to store all groups, to which the user belongs to, in the access token. But with this option the client has to ask every time the OAuth Service for a new token when the user gets a member of a new group.
So is there any other option how I could realize this szenario?
So, you have three domains:
Authentication: responsible for identifying the user
Authorization: responsible for restricting access to resources
Todos: your core domain
You have done well identifying three bounded contexts, one for each domain and implemented in three microservices (MS). You are conforming to the best practices regarding DDD.
No, your question is how could you integrate those three microservices in such a way that the system is resilient, i.e. its microservices continue to work even if some of the other microservices fail.
You have two options regarding integration (communication between microservices):
Synchronous communication: every time the Todos MS receive a request, it queries the Authorization MS to check if the user is permitted to do what it wants. This has the advantage that is simple to implement but it has the disadvantage that is susceptible to cascade failure: if the Authorization MS fails then this MS also fails. So, this option is not good for you.
Asynchronous communication: somehow in the background, there is some data that is replicated from the Authorization MS to the Todos MS. You have at least two options for this replication to be done: a) in cron or scheduled tasks or similar and b) using a event driven architecture. This has the advantage that provides more resilience but it has the disadvantage that is more complex, harder to implement. This option seems to fit your need.
Further reading:
Building microservices
I would suggest to put the authorisation handling into a API gateway. When there is an incoming request the following steps are executed
1.The API gateway hits the OAuth server to get a transparent token which contains the access roles and groups of the user
2.The API gateway then calls the to do services with the access token , which the to do services use to decide if a particular user is authorised.
The advantage of this integration pattern is that the individual services don’t have to call the group service to get the roles.
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