How to Organize Thins in Layers

How to Structure Project into Layers, Folders, Namespaces & Classes

Functional Cohesion or Spacial Locality or Use Case Oriented Org vs.

Categorical Cohesion or Components Type Cohesion or Framework Imposed

Classes, Folders, Name Spaces and Projects

Top level Folder Structure within this layer should be design around the

Functional Module within the Bounded Context/Application

Aggregate Root Entity Tree in the Domain Model

Views or UI Screens related to CRUD or Business Scenario having related Use cases

Use Case Module that group related Use Cases Together

Aggregate Root CRUD Management Module

Customers, Employees and Products are CRUD oriented Functional Module

Sale is the Business Scenario Orinted Related Sceens

"Set of CRUD Views/Screens Around some Functional Module/AggregateRoot"

Above is the criteria, used to structure the high level folders within the

different layers. This could be

Set of Related Views/Screens & Entities Around one Business Scenario

Set of Related Views/Screens & Entities Around Related Use Cases

There should be some Block Level Concept that group the related Use Cases

Use Case Module <== Containing Related Use Cases.

These are Vertical Slices with inthe Application

Component Types with in the Framework should not influence the top level

direcotry structure of application.

Web Delivery Mechansim should not inlfuence the top level dir strucuture.

Rather than Similar Components should be place together

We should place Components together those are related to Use Case.

===========================================

Presentation ==> Group Views related to a specific Aggregate Root.

Views realted to a particular Aggregate Root are kept together in a folder

and Folder is named after the Aggregate Root

AS ==> Group Application Services (Command & Queries) realted to

a specific Aggregate Root

Command/Queries/Use Cases realted to a particular Aggregate Root are kept

together in a folder and Folder is named after the Aggregate Root

DM ==> Group Domain Entites related to a specific Aggregate Root

Domain Model elements related to a particular Aggregate Root are kept together

in a folder and Folder is named after the Aggregate Root

Repository ==> Group Data Access Classes related to a specific Aggregate Root defined

against database table.

Table Oriented Repository classes related to a particular Aggregate Root

are kept together in a folder and folder is named after the Aggregate Root

Infrastructure Layer ==> Groups Classes by OS Components or by Third Party External

Dependency. External Systems with which our system will collaborate.

Email Service.

CCC Layer ==> Classes are organized according to the specific CCCs Aspect of the System

e.g. DataNTime, Logging, Security, Configuration,

=======================================================

CRUD oriented Aggregate Root

Business Scenario Oriented Aggregate Root

Business Functionality Oriented Aggregate Root.

UX + Information Arch ==>

Screens are Use Case Oriented

Screens are Aggregate Root Oriented

=======================================================

All Layers of the Application are roughly end up being Organized around the

Aggregate Roots and bear in Mind Aggregate Roots are of two types

1. Aggregate Root corresponding to the CRUD

2. Aggregate Root corresponding to the Business Scenarios

One Business Scenario ==> Many Related Use Cases

Aggregate Root corresponds to the UI Screens of the System

Aggregate Root and UI Screens Business Scenario are synonymous.

Top level folder structure of all layers aligns with the

UI Screens of the Application (CRUD Screens or Business Scenario Screens)

Aggregate Roots in the Domain Model (CRUD or Business Scenarios)

Business Scenarios (Having Related Business Use Cases)

CRUD Module (Having CRUD Use Cases)

Use Case Module (Having Related Use Cases)

==============================================