DDD refactoring: 1) Starting writing new classes; 2) diagramming the old schema.

Author: vkradio

.gitignore

@@ -229,6 +229,7 @@ ClientBin/
 *.pfx
 *.publishsettings
 orleans.codegen.cs
+*.~*
 
 # Including strong name files can present a security risk
 # (https://github.com/github/gitignore/pull/2483#issue-259490424)

FashionStore.sln

@@ -29,7 +29,14 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "misc", "misc", "{EF3ACB30-6
 EndProject
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ViewModelsTests", "tests\tests\ViewModelsTests\ViewModelsTests.csproj", "{9C8559E5-B6F4-4D2B-BF77-EC31495249F6}"
 EndProject
-Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ApplicationCoreLegacy", "src\ApplicationCoreLegacy\ApplicationCoreLegacy.csproj", "{AA3F6843-6E5B-42D9-8BFB-EA12590DEF4B}"
+Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ApplicationCoreLegacy", "src\ApplicationCoreLegacy\ApplicationCoreLegacy.csproj", "{AA3F6843-6E5B-42D9-8BFB-EA12590DEF4B}"
+EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "design", "design", "{B6FB1121-D255-47D9-84E3-017756A5BAD6}"
+	ProjectSection(SolutionItems) = preProject
+		design\DDD_old.uml = design\DDD_old.uml
+		design\DDD_old_Main.png = design\DDD_old_Main.png
+		design\DDD_old_Sales.png = design\DDD_old_Sales.png
+	EndProjectSection
 EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution

README.md

@@ -3,34 +3,32 @@
 ## Purpose and history
 
 This program is used in small network of fashion stores of one of my
-clients. It manages items in stock using visual size matrix. It
-supports a few warehouses, movement of goods between them, sells,
+clients. It manages items in stock using visualized size matrices. It
+supports multiple warehouses, movement of goods between them, sells,
 returns, reports and other typical features.
 
-There were already existed many store automation suites, but main
-motivation force for developing this another one was to be able to be
+Prior to this project, there were already existed many store automation suites, but main
+motivation for developing this another one was to be able to be
 used by employees without any PC experience, by “non-users”. The UI
 should've be as simple and intuitively understandable as possible. And
 that consideration has lead to many design constraints, so this software
 is essentially tailored to suit that particular client, and maybe not
-suitable at all for any “generic” fashion store.
+suitable to any “generic” fashion store.
 
 After many years I’m publishing it as an open source (with respective
 copyright permissions) as part of **my professional portfolio**.
 
-## Demonstration of my skills
-
-Current development is located inside of [efcore](https://github.com/vkradio/FashionStore/tree/efcore) branch.
+## Demonstration of my current skills
 
 ### 1. Project architecture
 
-The central part of the solution is an [ApplicationCore](https://github.com/vkradio/FashionStore/tree/efcore/src/ApplicationCore) subproject. It contains domain entities (according to DDD), service interfaces (to support DI) and other basic stuff. Entities, according to Single Responsibility principle, are almost 100% decoupled from any persistence storage infrastructure such as EF, JSON etc, they only contain Primary and Foreign Key properties when needed.
+The central part of the solution is an [ApplicationCore](https://github.com/vkradio/FashionStore/src/ApplicationCore) subproject. It contains domain entities (according to DDD), service interfaces (to support DI) and other basic stuff. Entities, according to Single Responsibility principle, are almost 100% decoupled from any persistence storage infrastructure such as EF, JSON etc, they only contain Primary and Foreign Key properties when needed.
 
-User Interface (in it's modern WPF Store Selection control) employs MVVM pattern. ViewModels are located in the dedicated project [ViewModels](https://github.com/vkradio/FashionStore/tree/efcore/src/ViewModels), they are totally ignorant of UI infrastructure (they are not coupled to WinForms or WPF or any other such dependencies). ViewModels have dedicated [unit tests](https://github.com/vkradio/FashionStore/tree/efcore/tests/tests/ViewModelsTests).
+User Interface (in it's modern WPF Store Selection control) employs MVVM pattern. ViewModels are located in the dedicated project [ViewModels](https://github.com/vkradio/FashionStore/src/ViewModels), they are totally ignorant of UI infrastructure (they are not coupled to WinForms or WPF or any other such dependencies). ViewModels have dedicated [unit tests](https://github.com/vkradio/FashionStore/tests/tests/ViewModelsTests).
 
-I do not use any third-party MVVM libraries here, so there is a simplest [MvvmInfrastructure](https://github.com/vkradio/FashionStore/tree/efcore/src/MvvmInfrastructure) project which contains reusable functionality such as subscription to property change events. Also I have a couple of miscellaneous utilities projects. And the remaining parts are legacy WinForms and custom DAL code which were just renamed to comply with modern practices.
+I do not use any third-party MVVM libraries here, so there is a simplest [MvvmInfrastructure](https://github.com/vkradio/FashionStore/src/MvvmInfrastructure) project which contains reusable functionality such as subscription to property change events. Also I have a couple of miscellaneous utilities projects. And the remaining parts are legacy WinForms and custom DAL code which were just renamed to comply with modern practices.
 
-Accordance to Single Responsibility principle in solution structure, where projects are loosely coupled with each other, allow us to relatively easy refactor and and extend functionality. For example, near [FashionStoreWinForms](https://github.com/vkradio/FashionStore/tree/efcore/src/FashionStoreWinForms) I can add FashionStoreWinFormsCore project with migration to .NET Core 3 WinForms, or FashionStoreWpf, if I would need to port it to WPF, or even FashionStoreAngular, if there will be a need to create an Angular SPA. I can add Web API subproject which will be a bridge to storage and other core functionality, and I can even restructure project to a set of different microservices and serverless function groups. For example, one microservice could contain functionality for sales person and another one - for business administrator.
+Accordance to Single Responsibility principle in solution structure, where projects are loosely coupled with each other, allow us to relatively easy refactor and and extend functionality. For example, near [FashionStoreWinForms](https://github.com/vkradio/FashionStore/src/FashionStoreWinForms) I can add FashionStoreWinFormsCore project with migration to .NET Core 3 WinForms, or FashionStoreWpf, if I would need to port it to WPF, or even FashionStoreAngular, if there will be a need to create an Angular SPA. I can add Web API subproject which will be a bridge to storage and other core functionality, and I can even restructure project to a set of different microservices and serverless function groups. For example, one microservice could contain functionality for sales person and another one - for business administrator.
 
 ### 2. Unit tests