Elements description

Elements/Domain/BuildingBlock.md

@@ -0,0 +1,43 @@
+# Building Block *[draft]*
+
+## Description
+
+*Building Block is a model for some domain concept.* It can model:
+- a thing like Car or Box
+- a concept like Tax Id
+- a behavior like Discount Calculator
+
+*There can be more precise types of Building Blocks* like Value Object or Process Step. These more precise types have different meanings and can have additional attributes and relations.
+
+*Building Blocks are atoms for Domain Model.* Every Element that is below Building Block in Domain Perspective like Behaviour or Rule have to me associated with some Building Block. Every Element that is above Building Block in Domain Perspective like Domain Module is a composition of Building Blocks.
+
+*Building Blocks are not a design patterns like patters from GoF.*
+
+## Aliases
+
+- DDD Building Block
+
+## Examples
+
+// TODO: Add examples
+
+## Attributes
+
+| Attribute name    | Data Type | Description                                                                                   |
+|-------------------|-----------|-----------------------------------------------------------------------------------------------|
+| Id                | string    | Unique identifier of the Domain Building Block e.g. *domainbuildingblock\|sales.orders.order* |
+| Name              | string    | Name of the Building Block e.g. *Order*                                                       |
+| Short description | string    |                                                                                               |
+
+## Relations
+
+| Relation name     | Related Element | Type        | Description |
+|-------------------|-----------------|-------------|-------------|
+| Depends on        | Building Block  | one to many |             |
+| Is implemented by | Code Structure  | one to many |             |
+
+## Children
+
+- [Process Step](ProcessStep.md)
+- DDD
+    - [Value Object](DDD/ValueObject.md)

Elements/Domain/DDD/ValueObject.md

@@ -0,0 +1,31 @@
+# Value Object *[draft]*
+
+## Description
+
+// TODO: Add description
+
+## Examples
+
+- *Money* - decimal value in certain currency with restricted set of arithmetic operations
+- *Tax Id* - business identifier for tax purposes
+- *Order Id* - technical identifier (e.g. int or UUID) for orders
+- *Offer* - offer in some domains can by only value that is calculated to compare it with other offers or create order base on it
+
+## Attributes
+
+| Attribute name    | Data Type | Description                                                                            |
+|-------------------|-----------|----------------------------------------------------------------------------------------|
+| Id                | string    | Unique identifier of the Domain Building Block e.g. *domainbuildingblock\|sales.taxid* |
+| Name              | string    | Name of the Building Block e.g. *Tax Id*                                               |
+| Short description | string    |                                                                                        |
+
+## Relations
+
+| Relation name     | Related Element | Type        | Description |
+|-------------------|-----------------|-------------|-------------|
+| Depends on        | Building Block  | one to many |             |
+| Is implemented by | Code Structure  | one to many |             |
+
+## External resources
+
+- [DDD Reference](https://www.domainlanguage.com/ddd/reference/)

Elements/Domain/DomainModule.md

@@ -0,0 +1,43 @@
+# Domain Module *[draft]*
+
+## Description
+
+**Domain Module is a separated, cohesive set of tightly connected building blocks that models business terms, behaviors
+and rules.**
+
+**Domain Module is not grouping by pattern or technical concerns.** Entities, Value Objects, Repositories, Services are
+not good names for Domain Modules.
+
+**Domain Modules can form a hierarchy.** One module can contains zero, one or many other modules. It's useful if domain
+is rather large and complex and can be naturally divided into smaller areas hierarchically arranged. Sometimes this
+hierarchy cen mimic enterprise organizational structure but it doesn't have to be one-to-one relation. It's more about
+business capabilities and responsibilities than about organizational structure.
+
+**Domain Module contains [Domain Building Blocks](BuildingBlock.md)**. Each Building Block belongs to only one Domain
+Module. Building Blocks inside single Module should be more tightly connected than Building Blocks from different Modules. Building Blocks from Modules closer in hierarchy should be more tightly connected than Building Blocks from Modules further in hierarchy.
+
+## Aliases
+
+- DDD Module
+
+## Examples
+
+- *Sales* - top level module for all business concepts related to sales activity
+- *Pricing* - a part of Sales module that is responsible for pricing and discounting
+- *Discounts* - a part of Pricing module that is responsible for calculating discounts
+
+## Attributes
+
+| Attribute name | Data Type | Description                                         |
+|----------------|-----------|-----------------------------------------------------|
+| Id             | string    | Unique identifier of the Domain Module e.g. *Sales* |
+| Name           | string    | Name of the Domain Module e.g. *Sales*              |
+
+## Relations
+
+| Relation name     | Related Element | Type        | Description |
+|-------------------|-----------------|-------------|-------------|
+| Contains          | Domain Module   | one to many |             |
+| Contains          | Building Block  | one to many |             |
+| Is deployed in    | Deployable Unit | many to one |             |
+| Is implemented by | Code Structure  | one to many |             |

Elements/Domain/ModelBoundary.md

@@ -0,0 +1,33 @@
+# Model Boundary *[draft]*
+
+## Description
+
+**Model Boundary is a boundary that separate a set of domain terms, behaviors and rules.** All elements within this boundary constitute separate model. Models from different boundaries should be as loosely coupled as possible. To integrate separate models explicitly defined public contract should be established. 
+
+**Within Model Boundary each term has precise and unambiguous meaning.** The same term in a different boundary can have different meaning. Integration of two models requires explicit translation of terms.
+
+**Defining Model Boundaries is an alternative to one canonical or corporate model for the entire domain.** Such one big model rarely can be unambiguous. As Eric Evans says: *total unification of the domain model for a large system will not be feasible or cost-effective*. Moreover several separate models better reflects business reality. Let's take for example business concept like product from ordinary e-commerce. We have many stakeholder here e.g. client, warehouseman, manager from revenue optimization department or even engineer that handles the complaint process. They do totally different things with a product so they need different behaviors, rules and data. Putting in all into single model is not a good idea. Instead we need separate, specialized models for all different meaning of a product. These models should live in a clearly established boundaries.
+
+## Aliases
+
+- DDD Bounded Context
+
+## Examples
+
+- *Sales* model for ale requirements from Sales department
+- *Pricing* model that is owned also by Sales department but has different product meaning and is used by several other models which don't need the rest of the *Sales* model
+- *Availability Management* model that doesn't map to any organizational division in the company but provides one of the basic business capabilities needed in many business processes
+- *Risk Scoring* model that is used in company's larger financial system and is also sold a separate product for other companies
+
+## Attributes
+
+| Attribute name | Data Type | Description                                                  |
+|----------------| --------- | ------------------------------------------------------------ |
+| Name           | string    | Name of the Model Boundary e.g. *Sales*                      |
+| Decision       | string    | Name of the design decision or link to this decision e.g. *ADR_027* |
+
+## Relations
+
+| Relation name | Related Element | Type        | Description                                                  |
+| ------------- | --------------- | ----------- | ------------------------------------------------------------ |
+| Contains      | Building Block  | one to many | One Model Boundary contains many Building Blocks. <br />Each Building Block belongs to only one Model Boundary. |

Elements/Domain/ProcessStep.md

@@ -0,0 +1,28 @@
+# Process Step *[draft]*
+
+## Description
+
+**Process Step is one of the Building Blocks that represents single step in a business process.**
+
+TODO: Add more description
+
+## Examples
+
+- *Place Order* step in *Online Ordering* process
+- *Calculate Discounts* step in *Online Ordering* process
+- *Calculate Taxes* step in *Invoicing* process
+
+## Attributes
+
+| Attribute name    | Data Type | Description                                                                                   |
+|-------------------|-----------|-----------------------------------------------------------------------------------------------|
+| Id                | string    | Unique identifier of the Domain Building Block e.g. *domainbuildingblock\|sales.orders.order* |
+| Name              | string    | Name of the Building Block e.g. *Order*                                                       |
+| Short description | string    |                                                                                               |
+
+## Relations
+
+| Relation name     | Related Element | Type        | Description |
+|-------------------|-----------------|-------------|-------------|
+| Depends on        | Building Block  | one to many |             |
+| Is implemented by | Code Structure  | one to many |             |

Elements/Elements.md

@@ -0,0 +1,19 @@
+# P3 Model Elements *[draft]*
+
+Here you can find the list of all elements of P3 Model. Each element has its own page with detailed description and examples.
+
+## Domain
+
+**[Domain Module](Domain/DomainModule.md)** - separated, cohesive set of tightly connected building blocks that models business terms, behaviors and rules e.g Risk Scoring, Pricing
+
+**[Building Block](Domain/BuildingBlock.md)** - model for some domain concept e.g Order, TaxId, Discount Calculator
+
+**[Process Step](Domain/ProcessStep.md)** - one of the Building Blocks that represents a step in a business process e.g. Place Order, Calculate Taxes
+
+### DDD
+
+**[Value Object](Domain/DDD/ValueObject.md)** - one of the Building Blocks that represents a value e.g. Money, Address
+
+## Technology
+
+## People

MetaModel.md

@@ -34,7 +34,7 @@ Each perspective contains multiple Elements of different types that represents d
 
 **We intentionally avoid using popular terms like module, container or component** because they have many different meanings in IT world and their meanings from common language don't tell us what it could be in the System.
 
-Full list of Elements grouped by Perspectives you can find [here](Elements.md).
+Full list of Elements grouped by Perspectives you can find [here](Elements/Elements.md).
 
 ## Relation