Skip to content

Organization

Walter Pinson edited this page Dec 15, 2017 · 10 revisions

Organization

Overview

One of the best ways to understand this reference architecture is to get familiar with the way that the source and supporting files are organized.

Folders

Top Level

Top Level Folders

Folder Name Description
./.circleci Contains CircleCI build configuration files
./postman Contains Postman collection and environment configuration files
./publish Contains distribution files necessary to publish the .Net Core WebApi application
./sh Contains bash shell scripts needed to configure environment and build the .Net Core solution
./src Contains application source code
./test Contains unit tests and integration tests

Top Level Files

File Name Description
./.dockerignore Instructs Docker to ignore files and folders when building images
./Dockerfile Instructions to build docker image
./docker-compose.yml Instructions to build a docker service
./.gitignore Instructs Git which files and folders are not to be copied into the repository
./NuGet.config Configure valid NuGet package sources
./reference-architecture-api.sln .Net Core solution file
./README.md Instructions to setup, build, and run the Reference Architecture API

Projects

The .Net Core solution file, reference-architecture-api.sln includes both application source and test projects. Additionally, there are some other projects that are not included in the solution but are included in the repository for demonstrative purposes.

The project are organized and named in accordance with the Onion Architecture.

Folder: /src

Project Name Description
Core Contains the entirety of the domain model and has no dependencies on other projects.
Infrastructure.Server Contains the implementation of the Core.Application
Infrastructure.WebApi REST API client of the Infrastructure.Server application
Infrastructure.Data.MongoDb Contains Core.Domain.Services repository implementations integrated with MongoDb
Infrastructure.Data.Sql Contains Core.Domain.Services repository implementations integrated with Sql Server
Infrastructure.Notifications.SendGrid Contains Core.Domain.Services notification service implementation integrated with SendGrid
Infrastructure.Notifications.Smtp Contains Core.Domain.Services notification service implementation integrated with SMTP
Infrastructure.Notifications.Sms Contains Core.Domain.Services notification service implementation integrated with Sms

Folder: /test

Unit Tests

Project Name Description
Test.Unit.Core Contains unit test harnesses for the Core project
Test.Unit.Infrastructure.Server Contains unit test harnesses for the Infrastructure.Server project
Test.Unit.Infrastructure.WebApi Contains unit test harnesses for the Infrastructure.WebApi project
Test.Unit.Infrastructure.Data.MongoDb Contains unit test harnesses for the Infrastructure.Data.MongoDb project

Integration Tests

Project Name Description
Test.Integration.Infrastructure.Data.MongoDb Contains integration test harnesses for the Infrastructure.Data.MongoDb project

Core Namespaces

The primary namespace is for this solution is CompanyName.Notebook.NoteTaking. This complies with the <company-name>.<product-name>.<service-name> format. Lower-level namespaces conform to the onion architecture and can be married up to the .Net projects.

  • CompanyName.Notebook.NoteTaking.Core
  • CompanyName.Notebook.NoteTaking.Core.Domain
  • CompanyName.Notebook.NoteTaking.Core.Domain.Models
  • CompanyName.Notebook.NoteTaking.Core.Domain.Factories
  • CompanyName.Notebook.NoteTaking.Core.Domain.Services
  • CompanyName.Notebook.NoteTaking.Core.Domain.Services.Impl
  • CompanyName.Notebook.NoteTaking.Core.Application.Messages
  • CompanyName.Notebook.NoteTaking.Core.Application.Services
  • CompanyName.Notebook.NoteTaking.Core.Application.Exceptions

All of these namespaces are pretty self-explanatory from an Onion / DDD perspective. CompanyName.Notebook.NoteTaking.Core.Domain.Services.Impl is worthy of additional explaination. This namespace includes Domain Service implementation classes that have no dependencies on external infrastructure. They are POCO domain service implementation classes.

Clone this wiki locally