What do you consider that is there relationship between DDD aggregate and architectural component? I think that it is quite reasoned that services, which are related to specific aggregate, defined a component structure.
When I’m modeling the domain model of my software, I’d find out several domain aggregates (with aggregate root) and, as you know, in DDD practice, each aggregate must handle as a single unit. Right?
Now simplified, the next stage is a higher level component structure modeling and I have to find out, which kind of components there exist. So could I consider that the each aggregate defined a new component and that component provides specific ports or interfaces for each business processes, which the encapsulated aggregate implements?
4
I think the answer to what you are trying to achieve is how to identify bounded contexts.
An aggregate on its own can indeed by thought of as a consistency boundary for all entities and value objects enclosed with in. However, you don’t expose your entities directly to the outside world.
To apply DDD effectively start by identifying your sub-domains. Find which of them is core, supporting or generic. Each of the core sub-domains should map optimistically to a bounded context (for example Shipping bounded context in an e-commerce system ).
A bounded context may be composed of several business component (Shipping.regularShipping and Shipping.priorityShipping).
Each business component may be further divided into components related to how each business domain might be implemented. For example, Shipping.regularShipping might be reading its data from a queue, so you might prefer to create a small micro service to consume that queue and store the data locally. You may need to calculate the dimension of the packaging, so you may create a small micro service just to perform that calculation.
Each bounded context will contain several layers. Some of these layers will be divided into ports which are simply entry points to your application (MVC web app, REST interface, SOAP interface, Scheduler calls). Some people call these the presentation or client layers of your bounded context.
The presentation layer calls into an application service which maps your use case from your domain. The application layer calls into the domain layer to load or create some aggregate and operate on it.
The domain layer houses your entities, value objects, domain services and interfaces to any infrastructure services you plan to use (mainly data storage using repositories).
The infrastructure layer houses the implementation for any technical services needed (accessing the database, cache control, encryption, logging, file system).
You might find Patterns, Principles, and Practices of Domain-Driven Design and Implementing Domain-Driven Design an interesting read.