|
|
@@ -1,21 +1,23 @@
|
|
1
|
1
|
------------
|
|
2
|
|
- Layering
|
|
|
2
|
+ Architecture
|
|
3
|
3
|
------------
|
|
4
|
4
|
|
|
|
5
|
+Architecture
|
|
|
6
|
+
|
|
5
|
7
|
The sample application is layered as illustrated by this picture:
|
|
6
|
8
|
|
|
7
|
9
|
[images/layers.png]
|
|
8
|
10
|
|
|
9
|
11
|
There are three vertical layers: interfaces, application and domain, each supported by different kinds of infrastructure.
|
|
10
|
12
|
|
|
11
|
|
- * Interfaces
|
|
|
13
|
+* Interfaces
|
|
12
|
14
|
|
|
13
|
15
|
This layer holds everythng that interacts with other systems, such as web services, RMI interfaces
|
|
14
|
|
- or web applications. It handles interpretation, validation and translation of incoming data. It also
|
|
15
|
|
- handles serialization of outgoing data, such as HTML or XML across HTTP to web browsers or web service
|
|
16
|
|
- clients, or DTO classes and distributed facade interfaces for remote Java clients.
|
|
|
16
|
+ or web applications, and batch processing frontends. It handles interpretation, validation and translation
|
|
|
17
|
+ of incoming data. It also handles serialization of outgoing data, such as HTML or XML across HTTP to
|
|
|
18
|
+ web browsers or web service clients, or DTO classes and distributed facade interfaces for remote Java clients.
|
|
17
|
19
|
|
|
18
|
|
- * Application
|
|
|
20
|
+* Application
|
|
19
|
21
|
|
|
20
|
22
|
The application layer is responsible for defining the use cases of the application, operations that can
|
|
21
|
23
|
are interface-independent and can be synchronous or message-driven. This layer is well suited for spanning
|
|
|
@@ -24,19 +26,29 @@
|
|
24
|
26
|
The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects
|
|
25
|
27
|
perform the actual work.
|
|
26
|
28
|
|
|
27
|
|
- * Domain
|
|
|
29
|
+* Domain
|
|
28
|
30
|
|
|
29
|
31
|
The domain layer is the heart of the software, and this is where the interesting stuff happens.
|
|
|
32
|
+ There is one package per aggregate, and to each aggregate belongs entities, value objects, domain events,
|
|
|
33
|
+ a repository interface and sometimes factories. The aggregate roots are Cargo, HandlingEvent, Location and Voyage.
|
|
30
|
34
|
|
|
31
|
|
- Everything below the domain package: domain service interfaces (and in some cases their implementations),
|
|
32
|
|
- repository interfaces (but not the implementations!) and the domain model with each aggregate in its own
|
|
33
|
|
- subpackage.
|
|
|
35
|
+ Everything about determining whether a handling event should be registered and how the delivery of a cargo
|
|
|
36
|
+ is affected by handling and belongs in here. The structure and naming of aggregates, classes and methods in
|
|
|
37
|
+ should follow the ubiquitous language, and you should be able to explain to a domain expert
|
|
|
38
|
+ how this part of the software works by drawing a few simple diagrams and using the actual class- and method names
|
|
|
39
|
+ of the source code.
|
|
34
|
40
|
|
|
|
41
|
+* Infrastructure
|
|
35
|
42
|
|
|
36
|
|
- Infrastructure
|
|
|
43
|
+ In addition to the three vertical layers, there's also the infrastructure. As the the picture shows, it supports
|
|
|
44
|
+ all of the three layers in different ways, facilitating communication between the layers. In simple terms,
|
|
|
45
|
+ the infrastructure consists of everything that exists independently of our application: external libraries,
|
|
|
46
|
+ database engine, application server, messaging backend and so on.
|
|
37
|
47
|
|
|
38
|
|
- In adition to the three vertical layers, there's also the infrastructure. As the the picture shows, it supports
|
|
39
|
|
- all of the three layers in different ways, facilitating communication between the layers.
|
|
|
48
|
+ Also, we consider code and configuration files that glues the other layers to the infrastructure as part of the infrastructure layer.
|
|
|
49
|
+ Looking for example at the persistence aspect, the database schema definition, Hibernate configuration and mapping files
|
|
|
50
|
+ and implementations of the repository interfaces are part of the infrastructure layer.
|
|
40
|
51
|
|
|
41
|
|
- Hibernate mapping metadata files, Spring context definition files, logging configuration.
|
|
42
|
|
- All external libraries,
|
|
|
52
|
+ While it can be tricky to give a waterproof definition of what kind of code belongs to the infrastructure layer for any given situation,
|
|
|
53
|
+ it should be possible to completely stub out the infrastructure in pure Java unit/scenario tests and still be able to
|
|
|
54
|
+ use the domain layer and possibly the application layer to work out the core business problems.
|
peter_backlund
пре 17 година