Design Accelerator: Ports and Adapters Architecture Part 3

[@niclash]

I would also separate the adapters to separate Gradle projects (Maven modules), to ensure that people later on don't introduce the popular Spaghetti-pattern and introduce dependencies in the wrong directions. That would then necessitate an "Application" project that binds the internals and adapters together.

[@VaughnVernon]

Right. You brought that up in Part 2 as well. I could do a brief follow up in the next video. I've done that before with Java but I'm not up to speed for how to do the same using a .NET build. I could just state that whatever build process you use could enforce the direction of dependencies.

[@z0nx]

Isn't that the whole point of P&A, direction of dependencies? In C# we also use projects to prevent dependencies going the wrong way since it doesn't allow circular references. However I much prefer the way F# deals with this by enforcing strict dependency ordering, even down to the function declarations in a file. Even though it may be a little annoying, it allows for code to become structured like P&A without even knowing about P&A.

[@christopherpetersen342]

Very interesting stuff! A few follow-up questions... The .io TLD may be changing (or going away!) because of geopolitical issues. How would you deal with that in your naming? And, which of these components would you choose to participate in a zero trust architecture? Would that be in the adapters, the ports, both, or would there be additional components doing that around what's shown?

[@VaughnVernon]

Thanks! All of your questions are good, yet out of scope for this tutorial. Whatever happens to .io will affect millions of companies and it won't just be dropped on the floor. Zero trust is a very large topic that I won't attempt to cover here, but possibly in a later video. Good ideas 😊

[@BlindVirtuoso]

Hi Vaughn. Nice one, appreciate it. Though I have a couple of questions: 1. What if we need to persist our Catalog using third-party API? Would there be just another implementation of CatalogRepository interface? 2. What if we also need to generate a PDF view of the Catalog while persisting it? Where would that application logic for generating PDF live? Thanks.

[@VaughnVernon]

Thanks! 1. Yes, sure. There are tradeoffs vs. temporary (or permanent) local storage followed by an API call. The details might get into the weeds so I'll stop there. 2. That introduces similar tradeoffs as with 1. Assuming you want the PDF generation to always happen, persisting the catalog data should occur first. Again, how you follow up with the PDF generation step is an implementation detail that I could cover in a later video.

[@BlindVirtuoso]

@@VaughnVernon Thanks a lot. Would be great to cover the details in your upcoming videos.

[@z0nx]

@8:22 now I'm curious why wouldn't you use application services? Anybody guess?

[@marco.garofalo]

I'd keep it simpler when it comes to packaging: - keep the app in the root of the package that hosts the bounded context, so in this case it would just have io.kalele.ecommerce and io.kalele.ecommerce.infra - avoid subpackaging the app, so I want to clearly see Catalog, CatalogRepository and CatalogService altogether, it makes it clear if the bounded context is growing too big I also have one question, I prefer not to use the word repository because it helps me think more about the language and the concept I am dealing with. For instance if I had a Product domain entity, I would probably call my repository ProductCatalog, rather than ProductRepository. In your example is there something in the domain that might actually be a better name candidate instead of CatalogRepository?