Clean Architecture

As you can see from the previous figure, the business logic lives near the UI and it depends on the data state layer. This is not a valid DDD layering but this is ok to keep our layered architecture simple. In the next part, we will introduce a real DDD layering.
If we consider the dashboard domain from Part 1 example, the domain folder structure will look like this (complete code here):

dashboards/
data/

domain/

dashboard.model.ts

resource/

ashboard.resource.ts // does actual http calls

store/

dashboard.store.ts
dashboard-shared.store.ts
index.ts

public/

state/

public-dashboard-state.module.ts
index.ts // re-export domain, shared state from data

feature-list/

list/

feature-list.component.ts
feature-list.adapter.ts <-- Business use cases feature-list-module.ts

feature-show/

show/

feature-show.component.ts
feature-show.adapter.ts <-- Business use cases feature-show-module.ts

components/

ui-dashboard-list.component.ts (display only)

patterns/ <-- Combinations of dump components
tokens/

In addition to the layered DDD, we use additional concepts:

Smart / Dump components: Or container / presentational components. Presentational components take input, show something, and provide output based on user interaction. These components have no logic and no dependencies. Whereas, container components or features have all the required logic to operate and manage child components.
Adapter service: Contains the business use cases for the underlying container component. Adapter uses the data state store state to enrich state data with business rules and provide the enriched data and functionality to the component. Adapter service is not a presenter pattern.

Figure 2 - Adapter service
Public scope: We only expose public folder contents to the outside world (global state store, other domains, and the application). In the best case scenario, we don’t have any dependencies between domains. But in case some domain A needs to use a container component from domain B, we should be careful how we design the rest of the components so we don’t end up with cyclic dependencies. In our example from Part 1, the sidebar domain will use a container component from the space domain and a container component from the dashboard domain, but neither the space domain nor the dashboard domain know anything about the sidebar domain. We enforce dependency direction and public/private scopes via ESLinting rules.
State sharing: To pass data (state) between domains, we can pass state exposed in the public layer in domain A to the state service/facade in the data layer in domain b.

Figure 3 -Cross domain state sharing