Added new files for Architecture_Core Introduction and Implementation

docs/Architecture/Core/Implementation.md

@@ -0,0 +1,57 @@
+# Design Principles
+
+![image](node-archi.png)
+
+The diagram above shows the conceptual structure of the node and the separation between the OS and Kernel.
+
+## OS
+
+The **OS layer** implements the application and infrastructure layers for the network. It also handles high-level network events and jobs, such as synchronizing the chain in response to a block announcement. Additionally, the OS layer includes the RPC implementation for the exposed API.
+
+## Kernel
+
+The **Kernel** contains smart contract execution primitives and definitions. It also defines the components necessary for accessing the blockchain's data. Various managers use the storage layer to access the underlying database.
+
+The Kernel also introduces the concept of plugins. The diagram shows that side chain modules are implemented as plugins.
+
+## Structure of the Project
+
+To understand AElf's structure, this section provides an overview of the solution.
+
+Conceptually, AElf is built on two main layers: **OS** and **Kernel**.
+
+- **OS Layer:**
+  - Contains high-level definitions for a node and endpoints like RPC and P2P.
+- **Kernel Layer:**
+  - Contains logic and definitions for smart contracts and consensus.
+
+AElf has a native runtime for smart contracts implemented in **C#**, for contracts written in C#. This implementation is found in the **AElf.Runtime.CSharp.\*** projects.
+
+A significant part of AElf is the side chain framework. It is mainly implemented in the **AElf.CrossChain** namespace, defining the main abstractions in the **core** project and an implementation with gRPC in the **AElf.Crosschain.Grpc** project.
+
+The **AElf.Test** solution folder contains all the tests. Ensuring maximum coverage of the main functional aspects is crucial for maintaining the quality of our system.
+
+Other projects implement libraries we use, like the crypto library, and others for infrastructure, like the database library. While not as critical, they are still worth exploring.
+
+## Jobs and Event Handlers
+
+Event handlers implement the logic that reacts to external and internal events. They represent the higher levels of the application, being called by the framework in a domain-agnostic manner. Event handlers, primarily using other services, influence the state of the chain.
+
+## Modules
+
+Our architecture is based on modules that are wired together at runtime. Any new module must inherit from **AElfModule**.
+
+To implement a new module, follow these steps:
+
+1. Write the event handler or the job.
+2. Implement the interface and create a manager or infrastructure layer interface if needed.
+3. Implement the infrastructure layer interface in the same project if no additional dependencies are required.
+4. Implement the infrastructure layer interface in another project if it requires third-party dependencies (e.g., adding gRPC, MongoDB, or MySQL in the new project).
+
+**Example:** The P2P network module.
+
+The networking code is defined across two modules: **CoreOSAElfModule** and **GrpcNetworkModule**. The OS core defines and implements the application service (used by other components of the node) as it is part of the application/domain logic. The infrastructure layer (like the server endpoint) is defined in the OS core modules but implemented in another project that relies on a third party, such as gRPC.
+
+## Testing
+
+When writing a new component, event handler, or method, it is important for AElf's quality to consider the corresponding unit test. As previously mentioned, we have a solution-wide test folder where we place all the tests.

docs/Architecture/Core/Introduction.md

@@ -0,0 +1,39 @@
+# Application Pattern
+
+We follow generally accepted good practices in programming, especially those that align with our project needs. Some of these practices are specific to C#, while others pertain to general Object-Oriented Programming (OOP) principles like **SOLID** and **DRY**.
+
+## Domain-Driven Design (DDD)
+
+Although it's uncommon for blockchain projects, we adhere to a Domain-Driven Design (DDD) approach in our development style. This approach is partly due to the compatibility of our main framework with DDD, making it a natural design philosophy for us.
+
+### Key Points of DDD:
+
+- **Four Traditional Layers:**
+  - **Presentation:** This corresponds to any type of dApp (Decentralized Application).
+  - **Application:** Exposed services mapped to different domains.
+  - **Domain:** Specific events related to our blockchain system and domain objects.
+  - **Infrastructure:** Third-party libraries for database, networking, etc.
+
+For more details, refer to our [coding standards](https://github.com/AElfProject/AElf/issues/1040) listed in our GitHub issue.
+
+## Frameworks and Libraries
+
+The primary programming language used for developing aelf is **C#**, and it's built with the **dotnet core** framework. This choice was made due to the excellent performance of the framework. Dotnet core is also cross-platform, supporting Windows, MacOS, and Linux. It is a dynamic and open-source framework, offering many advantages of modern development patterns and backed by major players in the IT industry.
+
+### Key Frameworks and Tools:
+
+- **ABP Framework:**
+
+  - We use the [ABP](https://abp.io/documents/abp/latest/Index) application framework.
+  - It is a natural fit for building blockchain nodes, which are sets of endpoints like RPC, P2P, and cross-chain communication, with higher-level protocols on top.
+
+- **Testing:**
+
+  - We use the **XUnit** framework for unit tests.
+  - Additionally, we have custom-made frameworks for testing smart contracts.
+
+- **Communication:**
+  - For cross-chain and P2P network communication, we use **gRPC**.
+  - We use **Protobuf** for serialization purposes.
+
+By following these practices and utilizing these tools, we ensure that our development process is efficient, reliable, and scalable.