You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a use case diagram. Use case diagrams overview the usage requirements for a system. They are useful for presentations to management and/or project stakeholders, but for actual development, you will find that use cases provide significantly more value because they describe "the meat" of the actual requirements. For more details, please see [here](http://www.agilemodeling.com/artifacts/useCaseDiagram.htm)
25
25
26
+
## Architecture
27
+
28
+
The general architecture can be seen here. It's still missing some things, but it's sufficient for most of the test we currently have.
A layer is a list of functions grouped together. For example, a database has functions for interacting with - the database! Yaay. The problem is that in most of the cases we need to be able to stub those functions - if we want to test some of the functions that _depend on the database_, then we have no option but to make them something that we can replace in runtime. And to replace them in runtime, we place them in a "layer", a record-of-functions that allows us to replace them easily. Like:
35
+
```
36
+
data IOLayer m = IOLayer
37
+
{ iolAppendFile :: FilePath -> Text -> m ()
38
+
, iolPrintText :: Text -> m ()
39
+
, iolReadFile :: FilePath -> m Text
40
+
, iolLogDebug :: Text -> m ()
41
+
, iolLogInfo :: Text -> m ()
42
+
}
43
+
```
44
+
45
+
We can think of a layer like a changeable module system - we export the functions in the data structure, but we can change them in runtime.
46
+
47
+
### DataSource
48
+
49
+
The data source is the place we get our data from. Currently, it's fixated on Zendesk. This is an abstraction towards any form of persistant data. We could say that this is a layer, but it actually contains quite a bit more.
50
+
Currently, the Zendesk types themselves are a pretty big part of the `DataSource` module.
51
+
52
+
### DataLayer
53
+
54
+
So the data layer is the abstraction layer which can currently be specialized to the @HTTPLayer@ or @DBLayer@. It makes sense to abstract this away, since this is the group of functions that interact with any data in the system.
55
+
56
+
#### HTTPLayer
57
+
58
+
Obviously, the direct way we can fetch data is using HTTP JSON requests on the Zendesk API (https://developer.zendesk.com/rest_api/docs/core/introduction). This layer is the layer responsible for that. It contains common functions that allows us to communicate with the Zendesk REST API.
59
+
60
+
#### HTTPNetworkLayer
61
+
62
+
This layer is the layer responsible for the low level HTTP communication. The @HTTPLayer@ is the layer that communicates with the Zendesk REST API using this layer.
63
+
64
+
#### DBLayer
65
+
66
+
This layer is responsible for caching the results that come from the @HTTPLayer@ and then allows us to fetch data from the database rather then the HTTP REST api which has request limits and takes much longer.
67
+
26
68
### Overview
27
69
28
70
- Many of the Daedalus's issues can be identified by analyzing the log file. The classifier will utilize this by analyzing the log file and map with possible solution and problem which can be provided to the end user.
0 commit comments