1

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?

closed as unclear what you're asking by Dan Pichelman, Ixrec, GlenH7, Bart van Ingen Schenau, user40980 Feb 4 '16 at 17:49

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Hi Triton, what do you mean exactly by "architectural component"? – Songo Jan 27 '16 at 9:51
  • It is a part of structure of the software, which encapsulates logically interconnecting business behaviour inside of it. – Toni Jan 27 '16 at 21:11
  • I think you should give a direct concrete example with more details to what you trying to ask. You question as it is is too vague and will attract down-votes. – Songo Jan 27 '16 at 21:24
  • Now I have added (hopefully) better explanation. – Toni Jan 28 '16 at 22:27
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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.