1

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? – 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
  • 1
    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/… – 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
0

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) 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:

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?" – Robert Harvey Jul 29 '18 at 14:51
  • @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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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