Domain driven design - factory with cross-cutting concerns

Question

I was recently tasked with creating a factory that processes webhook events. Any authorized application in the solution (1 app per domain) can post any meaningful payload and as long as the event's wired up for processing it should be able to handle it.

I have two domain projects: Core (logging, security, & common functionality) and let's call it App1. Ideally, App1 should always reference Core, but Core should never reference App1 for scalability purposes (many things can reference Core).

The factory has the potential to call App1, App2, App3, etc... thereby my question is how are these one-offs typically handled in a domain driven design architecture?

For you case, is the factory intended to be owned by Core, or individual apps? — eparham7861, Jul 24 '18 at 21:11
@eparham7861 The factory is currently in core and injects factories (and their methods) from individual apps to process the payloads. — RandomUs1r, Jul 24 '18 at 21:22
Domain-Driven Design isn't an architecture; it is a *design process.* DDD helps *discover the top-level architecture* and inform about the mechanics and dynamics of the domain that the software needs to replicate. See http://www.drdobbs.com/architecture-and-design/domain-driven-design-the-good-and-the-ch/240169117 — Robert Harvey, Jul 24 '18 at 21:40
Can you provide a little more detail about what a typical webhook event might look like? — Robert Harvey, Jul 24 '18 at 21:48
@RobertHarvey Sure, design dictates the architecture (fallacies aside) with plenty of edge cases in between is my understanding. A couple of events are "document viewed" and "invite accepted". The strategies and their concretes would live in their respective domain projects leaving the cross cutting in place (Core would reference App1's strategy) though I'll admit the boundary would be much more clearly defined, but still not uni-directional. — RandomUs1r, Jul 24 '18 at 22:00
Between Core, App1, and App2, what would Core reference from App1 for App2, assuming that is a valid direction? Also, why wouldn't any of the apps be using the Core factory to setup/generate the concrete implementation of a webhook to another app for the specified event, where the core accepts, or retrieves from some storage, the criteria for another app's webhook? — eparham7861, Jul 24 '18 at 22:55
Although confusingly named App1, App2, etc., they are really all part of the same application (according to the organization implied in your question). The term "Composition Root" might help you out here. — user3347715, Jul 25 '18 at 15:03
Domain-Driven-Design is about business-domains. In my opinion "factory with cross-cutting concerns" is a technical topic and not a busines-topic and thererfore has nothing to do with "Domain Driven Design" It is a software architecture topic. **Without knowning which environment/programming language you are using the answer is to broad.** — k3b, Apr 20 '20 at 12:52

candied_orange · Answer 1 · 2020-04-20T12:31:33.230

App1 should always reference Core, but Core should never reference App1

That screams plugin.

               AppN       |          Core
-----------------------------------------------------
                          |
    CommonResultUser    -- -|>     IOutputPort  
                          |             ^
                          |             | 
                          |             | 
                          |    CommonFunctionality
                          |             |
                          |             _
                          |             V
CommonFunctionalityUser -- -->     IInputPort
                          |

The flow of control goes through all of this counterclockwise. Notice all static code dependencies go from App to Core. Core has no idea Apps even exists. Core just provides interfaces that must be used to talk and listen to it.

Construction in main (which knows about everything and nothing else knows about) might look like:

CommonFunctionalityUserInApp1 user = 
    new CommonFunctionalityUserInApp1(
        new CommonFunctionalityCore(
           new CommonResultUserInApp1()
        )
    )
;

Which you are free to shove in a factory, if you feel some need to.

Use might look like:

user.commonProcedure();

And it all might remind you of this:

I'd go on but I've talked about this before.^1,2

All this presumes you really do want the AppNs to not be the center of their respective programs and really do want common functionality in your core. Alternatively, common functionality can be moved out into a library.^3,4

@RobertHarvey It's not just about interfaces. It's about what owns them and so dictates if they change. That controls what knows about what. And truthfully you can make this work in languages that have no interface keyword. — candied_orange, Jul 29 '18 at 14:57
Hmm... Well, I think you got it right with your first sentence: "This screams plugins." Late-binding is the answer; simply instantiate your class without using a static reference. — Robert Harvey, Jul 29 '18 at 15:01

Domain driven design - factory with cross-cutting concerns

1 Answers1