Merge pull request #2 from madetech/kotlin-draft

Kotlin draft

Author: craigjbass

README.md

@@ -31,7 +31,18 @@ In Made Tech Flavour Clean Architecture we stick to the name "UseCase"
 
 # Domain 
 
-These contain the "Entity" objects
+Domain objects are the center of your system. 
+Their purpose is to model the domain, in the Object-Oriented world.
+
+The challenge is determining what behaviours lie within Domain objects, and what behaviours lie within Use Cases.
+
+A good rule of thumb is that behaviours within Domain objects *must be valid for all Use Cases across the system.*
+
+It is cheaper to specialise Use Cases, resulting in an anemic domain model, then evolve the systems towards generalisations once patterns emerge.
+
+## Alternative names
+
+* Entities
 
 # Gateways
 

kotlin/Domain.md

@@ -0,0 +1,2 @@
+# Domain
+

kotlin/Gateway.md

@@ -0,0 +1,4 @@
+# Gateway
+
+Contains IO adapters (e.g. files, database or API calls)
+These construct Domain objects for use by Use Cases, and, save Domain objects given to it

kotlin/README.md

@@ -0,0 +1,23 @@
+# Made Tech Flavour Clean Architecture: Kotlin 
+
+Example project: [MLD Klean Architecture (Continuous Feedback)](https://github.com/madetech/dojos/tree/67eb97d93135ae0fc54bada70e2d2656f7873b88/mld-klean-architecture)
+
+## [Testing](../learn/ATDD.md)
+### Spek
+
+#### Acceptance Test
+An executing [example can be found here](https://github.com/madetech/dojos/blob/67eb97d93135ae0fc54bada70e2d2656f7873b88/mld-klean-architecture/src/test/kotlin/io/continuousfeedback/core/test/acceptance/TeamNotificationsSpec.kt).
+
+#### Unit Test
+An executing [example can be found here](https://github.com/madetech/dojos/blob/67eb97d93135ae0fc54bada70e2d2656f7873b88/mld-klean-architecture/src/test/kotlin/io/continuousfeedback/core/test/unit/CreateTeamMemberSpec.kt).
+
+
+## Production Code
+
+Customer code should be housed within a Client package e.g. ```com.acmeindustries.widget```
+
+Non-customer specfic code should be housed within a MadeTech namespace e.g. ```com.madetech.authentication```
+
+* [Use Cases](UseCases.md) use_case/ 
+* [Domain](Domain.md) domain/
+* [Gateway](Gateway.md) gateway/

kotlin/Spek.md

@@ -0,0 +1 @@
+# Spek

kotlin/UseCases.md

@@ -0,0 +1,64 @@
+# Use Cases
+
+Use Cases can be both asynchronous and synchronous.
+
+The primary difference is that a synchronous Use Case will return it's result, and an asynchronous Use Case will call a callback with it's result.
+
+It is possible to generalise the boundary interfaces of these two types of Use Cases.
+
+## Asynchronous Example
+
+Asynchronous use cases provide greater control over rendering to the UI. However they add complexities to testing.
+
+An [example generalisation can be found here](https://github.com/madetech/dojos/blob/master/mld-klean-architecture/src/main/kotlin/com/madetech/clean/usecase/AsynchronousUseCase.kt), 
+with [a derivative here](https://github.com/madetech/dojos/blob/master/mld-klean-architecture/src/main/kotlin/io/continuousfeedback/core/usecase/CreateTeamMember.kt) for a specific use case.
+
+```kotlin
+package com.acmeindustries.widget.usecase
+
+interface ViewWidgets {
+ fun execute(request: Request, presenter: Presenter)
+ 
+ data class Request(...)
+ interface Presenter {
+ fun onSuccess()
+ fun onError()
+ }
+}
+```
+
+
+## Synchronous Example
+
+Synchronous Use Cases provide a simpler interface for testing, but can make representing failure paths and control over the UI harder to maintain.
+
+```kotlin
+package com.acmeindustries.widget.usecase
+
+interface ViewWidgetPerFooBarReport {
+ fun execute(request: Request): Response
+ 
+ data class Request(public val fromDate: String, public val endDate: String)
+ data class Response(...)
+}
+```
+
+```kotlin
+package com.acmeindustries.widget
+
+import com.acmeindustries.widget.usecase.ViewWidgetPerFooBarReport
+import com.acmeindustries.widget.usecase.ViewWidgetPerFooBarReport.*
+import com.acmeindustries.widget.domain.Widget
+
+class WidgetPerFooBarReport(val widgetGateway: WidgetGateway) : ViewWidgetPerFooBarReport {
+ fun execute(request: Request): Response {
+ val widgets = widgetGateway.all()
+ //secret sauce here
+ return Response(...) //return response populated with data
+ }
+}
+
+interface WidgetGateway {
+ fun all(): List<Widget>
+}
+```

learn/ATDD.md

@@ -0,0 +1,26 @@
+# ATDD
+
+## Acceptance Testing
+
+The purpose of acceptance testing is to test an entire system via it's boundary only.
+It serves as a *stand-in*, and documentation for the implementation of the future UI of your system.
+Anything that you are coupled to in your acceptance tests, you are also going to be coupled to in your UI.
+
+This means an acceptance test, cannot depend on the following types of objects:
+
+- Domain objects 
+- Gateways 
+
+It must only depend on the *Boundary* of your system.
+
+**The purpose of acceptance tests** is to measure success towards the goal of meeting the customer's needs, and reduces the 
+occurrence of gold plating
+
+## Unit Testing
+
+Unit Tests are able to break these rules of acceptance tests. 
+It is meant to serve as documentation of the behaviour of lower level components.
+Since these tests are lower level it is possible to test-drive the system into performing every possible permutation of behaviour under a test situation.
+
+This gives the property of [(semantic stability)](https://www.madetech.com/blog/semantically-stable-test-suites) .
+

learn/README.md

@@ -23,6 +23,10 @@ In extension to the Agile manifesto, clean architecture's core values and belief
 * Any aspect of the codebase should be considered opportunity for refactoring at any time.
 * The SOLID and Package principles are core guiding principles used to determine the Clean Architecture paradigm.
 
+## Other guides
+
+* [ATDD](ATDD.md)
+
 ## Core Skills
 
 * Able to describe