What is a framework from DDD perspective?

Question

Frameworks solve problems in a generalized way, so we can reuse the code and the language if we want to solve a related problem in our application. We meet with them typically by integration, but what if we have a framework which implements a complete subdomain? For example identification and authorization? Should we use it? What is it from DDD perspective, is it a bounded context?

Answer 1

Decide, if buy or build

Let's we are in some kind of security domain (our core domain). The security software that we will build, going to be our company advantage.
In here it has no sense to buy/use some public authorization component. We will want continuously make such component better.
If we wont, our company will stop increasing its business value and we can't allow that.

From the other side, if we are in selling domain, we may want to want to use external component.
This is related with time, that we need to spend on building/maintaining it.
If this is much time, we will lose time that we could spend on incresing our business value in selling component.
Also we may have no security experts, because it's not our domain. We may read some books/articles, but we probably won't deliver as good software as company who's core domain is security :).
That is why we should really consider buying such component.

When it's just Subdomain and when it becomes Bounded Context

 "What is it from DDD perspective, is it a bounded context?"

Bounded Context as a term is very abstract.
From my perspective we may talk about bounded context (the good one, which goes one to one with subdomain), when we have

• One application
• Model, that is surrounded by UL
• Application which exposes external API, so other application may talk to it
• Probably some storage, that will contain all our model states.
• All infrastructure, that is needed to run the app

Framework from it's definition is just an skeleton, you can't just download framework and run it. It will not provide any value. So framework just helps us to build Bounded Context around some subdomain, but it doesn't provide BC by itself.

Using external components/frameworks

If it's component ready to deploy and exposing some API, we would just go with integration patterns.

"what if we have a framework which implements a complete subdomain?"

If it's a framework, then depending on the need.

1. We may build a bounded context around it, by adding some code and exposing some external interface.
2. We may add it, to our bounded context which is probably describing some other subdomain. As long as it doesn't break our model it's fine.
   Our bounded context will just cover more than one subdomain. The subdomains, should be in separate packages named after UL.
   You will probably want to have as less as it's possible connections between those two modules.
   You may even build ACL on the domain level. This is only to help your model grow, without taking care of all those other's subdomain complexitivity. Think of this code as thing that you may want to cut off some day and integrate with it, with public interface.

Answer 2

Actually depending on your framework it could also be a domain service.

For example a framework that would implementent a service.IsAuthenticated(someDomainObject) seems like a very reasonable service.

Domain Driven Design: Domain Service, Application Service