"one single assembly for the whole Infrastructure part" ... so that single assembly would contain all of the "outside" code? And therefore, in theory, web code could bypass the domain model and call the database code directly? ;-)
If anything, I've probably made the situation worse! Judging by the discussions I've had, the blog posts out there and the questions on places like Stack Overflow, I don't think it's really clear what ports & adapters is really about. Most examples being subtle twists on a layered architecture doesn't really help too. I believe there's an opportunity to create a canonical ports & adapters example, but physical separation of code needs to be a big part of this ... it's essentially a plugin architecture, where adapter implementations are plugged in to the application at runtime. I think that's a far more compelling description of ports & adapters that a simple variation of a layered architecture. The downside is this requires a much more rigorous and disciplined approach to development because you need to create an environment where domain code absolutely cannot see/use those adapter implementations directly. One assembly or source code project/module per adapter gives you that compile time check that the inside code isn't depending on the outside code. But those additional assemblies/source code projects/modules are a trade-off I don't think people are willing to make. Without this physical isolation, we're really back to a variation on a well implemented layered architecture.
E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).