Comments (6)
This is something I've been meaning to take a closer look at, so I'm excited to see you post!
Currently, the domain does not have any concept of users (although I could easily see a requirement for being able to see who reported the incident or booked the cargo). My take is that any domain concepts in the context object should be extracted and passed to an application service (as opposed to sending the context to every service method). E.g.
AssignCargoToRoute(id cargo.TrackingID, itinerary cargo.Itinerary, assignedBy user.ID) error
If the user ID was a part of the domain, my first attempt would be to decode the user ID into a UserID
field in the request struct, or possibly extracting it from the context obj in the makeEndpoint
functions.
If we're to use the token only to authorize the API call, then I would consider writing a endpoint.Middleware
where I'd decode the token and continue only if it was valid.
from goddd.
Thank you for comprehensive and quick answer.
from goddd.
User is not supposed to be a part of domain. Then if I use token with user ID for authorization, every endpoint and every request use the same authorization logic, should I repeat the middleware code in every application service? Wouldn' itt be idiomatic to have some common/shared middleware that serves every request? Where should we place such middleware? By the way I use alternative layout with domain object in root dir.
from goddd.
Yeah, I could see a jwt
subpackage providing the middleware functionality. There's also a PR to add this to go-kit as well, that might serve as inspiration go-kit/kit#335
from goddd.
Thanks. I'll check it.
from goddd.
@valsor, not sure if this helps at all, but I've taken "authentication" to be its own domain package including its own service and middleware modules that are then referenced by (generally) the endpoint module of each domain package that requires these features.
You mention a few things that I may be able to address, and understand that I'm a bit of a Go neophyte and not an expert on DDD so someone with more experience please correct me if I stray from the light:
User is not supposed to be a part of domain.
If your data model includes a "user" as a basic component, then it is indeed part of your domain. I think what you're concerned about is mixing the domain concept of a "user" with the authentication concept of "the user performing this action". I've skirted this by instead using the concept of a "principal" in my authentication domain. The "principal" abstracts away the details of the true actor in this equation and exposes only two things: a method to uniquely identify the actor and a list of access claims the actor has made.
These primitives seem to jive well with just about every authentication system you may use. The middleware (which is an actual endpoint.Middleware
) provided by the authentication package is then only required to parse the token/credentials from the inbound request, retrieve the principal they correspond to and add this information to the context.
The actual invocation looks something like this, when setting up an endpoint in a domain package:
someEndpoint = makeSomeEndpoint(...)
someEndpoint = authentication.Restrict("users:update")(someEndpoint)
from goddd.
Related Issues (20)
- Does the implementation of routing service really belong to booking? HOT 1
- RequestPossibleRoutesForCargo returns domain objects HOT 1
- Application services use both DTOs and domain objects HOT 3
- routing package contains both domain and infrastructure
- Improve test suites HOT 1
- inspection.EventHandler needs implementation
- Adopt a package management tool / makefile HOT 3
- Add validation of domain objects HOT 10
- Examples using SQL and relational models. HOT 8
- improving package names HOT 4
- Question about aggregates HOT 2
- Docker example failure to start. HOT 1
- Returning interfaces? HOT 3
- Moving source code to src/pkg/app directory HOT 2
- Database transactions HOT 4
- invalid memory address or nil pointer dereference
- Use forms in POST requests
- http://dddsample.marcusoncode.se/docs/ HOT 2
- Extract server package
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from goddd.