0

I am reading Domain Driven Design by Eric Evans and there are 2 sub-chapters - Abstract Core & Pluggable Component Framework - that seems to me to refer to the same concept. I believe that there is a subtly difference, but I am missing it.

Abstract Core

Identify the most fundamental concepts in the model and factor them into distinct classes, abstract classes, or interfaces. Design this abstract model so that it expresses most of the interaction between significant components. Place this abstract overall model in its own MODULE, while the specialized, detailed implementation classes are left in their own MODULES defined by subdomain.

Pluggable Component Framework

Distill an ABSTRACT CORE of interfaces and interactions and create a framework that allows diverse implementations of those interfaces to be freely substituted. Likewise, allow any application to use those components, so long as it operates strictly through the interfaces of the ABSTRACT CORE.

In both situations, the author refers to distilling an Abstract Core and in both situations, as per my view, this Core will describe how components fit together. Also, at the Pluggable Component Framework chapter, the book has an example with the software from SEMATECH (SEMATECH CIM Framework) which does exactly what the Abstract Core is saying it should do.

An example that would make the difference more obvious would help understand the concepts better.

1

So, the first quote describes what the author means by "Abstract Core". When modeling the Core Domain, you are going to have "surface level" elements that are visible to clients (the application logic, use cases), and act as an API to the "inside" of the core, so that you can manipulate the implementation details when developing/refactoring. These "surface level" classes / functions / data types represent the fundamental capabilities of the core model, and are, ideally, designed to be expressive enough so that the logic of the clients can be expressed in terms of those elements; this is the Abstract Core.

In the book, when a concept is rendered in ALL CAPS, it generally means that it's a reference to a concept defined elsewhere in the text.

Now, having an abstraction (such as an Abstract Core) does not automatically mean that it's extensible, or that the behind-the-scenes implementation is partially or fully swappable from the perspective of clients, or via a composition root (if the application is using DI). In case of "fully swappable", the Abstract Core presumably performs some useful higher-level function. To support this kind of extensibility, the Abstract Core needs to be specifically designed for it (and this is not necessarily an easy thing to do well, and not without costs, so this shouldn't be taken as a rule, but as one of the options to consider). You need to plan for & define extension points where external code can be plugged in (e.g., by implementing an interface or a base class, and registering itself via some API). So in the second quote, the emphasis is really on the "and create a framework that allows diverse implementations of those interfaces to be freely substituted."

For the last bit, "allow any application to use those components", imagine a library of reusable components (not generic ones, but for a specific aspect of a domain) that clients (or application compositors) can freely pick and plug in into this framework to configure for the functionality they need, or a scenario where each application team can make use of the services provided by the Abstract Core, but develops their own components for details. The client logic itself would go through the framework / abstract core; this requires some programming discipline, team maturity, and it puts a bit of a burden on clients in the sense that they need to be aware of (some of) these components in order to pick the ones that are suitable for their needs; this can be mitigated if you can provide sensible defaults.

Note that this chapter starts with:

Opportunities arise in a very mature model that is deep and distilled. A PLUGGABLE COMPONENT FRAMEWORK usually only comes into play after a few applications have already been implemented in the same domain.

So, the idea is that this is something that may be produced as a result of refined understanding of domain concepts over several applications, each of which likely has its own model (representation) of the same domain, with significant conceptual overlap. The Abstract Core in this scenario captures that overlap (i.e., it does something of central value to all those applications), and is also designed to support application-specific needs by allowing for pluggable behavior. The book also notes that efforts in this direction have had mixed success, with those doing this later rather then earlier (so, after several applications have already been developed) being more successful.

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.