- Account creation just once.
- Transaction authorization for the created account.
- Error handling transforming to violations any violation of expected business rule.
- Kotlin
- Gradle
- Docker
- We decided to use the
Package by Feature approachto present the project by the problem that he solves and not by the way that will be provided to the user and organize the packages to have more cohesion and high modularity, and with minimal coupling between packages. If you want to read more about package by feature click here
- Jackson to transform Json Strings to Objects
- Mockk to Mock some objects in the tests
- AssertJ to make more fluent the tests with exception
- Shadowjar to create the fat jar that will be use in the Dockerfile
- Docker
docker build -t bank-account .
- Gradle
gradle clean build
-
Docker
docker run --rm --name bank-account -it bank-account
-
Gradle
gradle clean test run
-
Send event messages, like:
{"account": {"active-card": true, "available-limit": 100} }
{"transaction": {"merchant": "Burger King", "amount": 20, "time": "2019-02-13T11:00:00.000Z" }}
{"transaction": {"merchant": "Habib's", "amount": 20, "time": "2019-02-13T11:00:00.000Z" }}- If you want to process the events just add an empty line like if you are consuming a unix file (EOL Unix).
- Always need to be just one or none account active at the same time.
- Creation of some interfaces to make the project easy to be extensible like if the project needs to change the data source (
DataConsumer,Reader,OperationEvent,Operation,OperationViolation). - We implemented a
batchapplication to read some transactions based in a specific account but if we need to implement astreamreader we can easily add this just creating another implementation for theDataConsumer. - To execute the event list process you need to insert a empty line (like EOL Unix file).
- The transaction events always will be ordered by
time. - The return of transaction events process will be returned in the order of
time. - As the execution is sequential we decided for no multi-thread approach but something could be implemented with corroutines or workers.
| Package | Class, % | Method, % | Line, % |
|---|---|---|---|
| all classes | 97.6% (41/ 42) | 99% (97/ 98) | 94.7% (161/ 170) |
| Package | Class % | Method % | Line % |
|---|---|---|---|
| br.com.bank | 0% (0/ 1) | 0% (0/ 1) | 0% (0/ 9) |
| br.com.bank.infra | 100% (2/ 2) | 100% (4/ 4) | 100% (6/ 6) |
| br.com.bank.operation | 100% (8/ 8) | 100% (13/ 13) | 100% (27/ 27) |
| br.com.bank.operation.account | 100% (12/ 12) | 100% (34/ 34) | 100% (59/ 59) |
| br.com.bank.operation.account.transaction | 100% (7/ 7) | 100% (17/ 17) | 100% (32/ 32) |
| br.com.bank.operation.consumer | 100% (1/ 1) | 100% (2/ 2) | 100% (2/ 2) |
| br.com.bank.operation.consumer.stdin | 100% (2/ 2) | 100% (4/ 4) | 100% (8/ 8) |
| br.com.bank.operation.processor | 100% (1/ 1) | 100% (2/ 2) | 100% (6/ 6) |
| br.com.bank.operation.validation | 100% (1/ 1) | 100% (2/ 2) | 100% (2/ 2) |
| br.com.bank.operation.validation.violation | 100% (7/ 7) | 100% (19/ 19) | 100% (19/ 19) |
Generated on 2020-03-02 18:28
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent