eShopOnWeb has an interface called IAggregateRoot which has no methods or properties… what’s that about?
Well empty interfaces like this are often referred to as ‘marker’ interfaces and this pattern is often used to flag classes as being of some kind of type.
We can use the marker interface pattern as an extra contextual clue to communicate intent to other developers and to enforce design constraints. For example we can see below that the only classes allowed to implement the IRepository interface are those of type IAggregateRoot.
Click on the image for a larger view in a new tab…
Is the marker interface pattern useful?
Is it really needed?
IMHO it’s vital when we are working on a platform, open source software, a framework, a library etc.. when we never meet the devs who are consuming our code to provide a steer and guide these external developers as much as possible. In this case marker interfaces can definitely be a useful addition to the overall architecture.
On the other hand when we are working in a closed loop with a bunch of developers we talk to everyday marker interfaces might be a bit superfluous. I think there’s probably other ways to make sure a developer doesn’t create an repository for OrderLine.cs (for example) as its not an aggregate root… eg.. code reviews, PRs etc.
… And remember there’s nothing to stop a developer having OrderLine.cs implement IAggregateRoot to ‘bypass’ design constraints.. so ultimately it still all comes down to developers not making mistakes.
Microsoft recommends against them
Note… Microsoft actually recommends against the marker interface pattern on their Interface Design page and suggests using attributes instead…
… unfortunately its not possible to enforce constraints against attributes as easily as it is against types.
One thought on “eShopOnWeb Architecture (1/16) – uses marker interfaces to communicate intent and enforce design constraints”