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?

  • 1
    For you case, is the factory intended to be owned by Core, or individual apps? Commented Jul 24, 2018 at 21:11
  • @eparham7861 The factory is currently in core and injects factories (and their methods) from individual apps to process the payloads.
    – RandomUs1r
    Commented Jul 24, 2018 at 21:22
  • 4
    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 drdobbs.com/architecture-and-design/… Commented Jul 24, 2018 at 21:40
  • Can you provide a little more detail about what a typical webhook event might look like? Commented Jul 24, 2018 at 21:48
  • 1
    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. Commented Jul 25, 2018 at 15:03

1 Answer 1


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:


And it all might remind you of this:

enter image description here

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

  • So basically "decouple with interfaces?" Commented Jul 29, 2018 at 14:51
  • 1
    @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. Commented Jul 29, 2018 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. Commented Jul 29, 2018 at 15:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.