Architecture

序本文次要钻研一下Ports and Adapters architecture Ports and Adapters architecturePorts and Adapters architecture，又叫Hexagonal architecture，其中ports层是六边形的边界，其中port又能够分为driver port及driven port，简略了解对应输出层及输入层；边界爱护的是外部的app，其中app包含use cases或者叫做application services层以及domain层；adapter能够了解为将内部依赖进行适配，实现port层定义的接口 示例构造github.com/albertllousas/implementing-hexagonal-architecture ├── app│ ├── domain│ │ ├── Account.kt│ │ ├── Ids.kt│ │ ├── Transaction.kt│ │ └── Transfer.kt│ ├── port│ │ ├── driven│ │ │ ├── AccountBalanceChecker.kt│ │ │ ├── AccountFinder.kt│ │ │ └── Transactor.kt│ │ └── driver│ │ └── TransferMoney.kt│ └── usecase│ └── TransferMoneyUseCase.kt└── infrastructure ├── adapter │ ├── driven │ │ ├── InMemoryAccounts.kt │ │ └── InMemoryTransactions.kt │ └── driver │ └── ktor │ └── TransferHttpRoutes.kt └── config ├── ApplicationModule.kt └── ApplicationRunner.ktport层这里定义了driven及driver两大类的接口，而后adapter层对应driven及driver这两大类应用内部的服务进行实现；domain层定义了domain model以及相干畛域办法；usecase或者是application service层则是编排小结Ports and Adapters architecture，又叫Hexagonal architecture，其中ports层是六边形的边界，其中port又能够分为driver port及driven port，简略了解对应输出层及输入层；边界爱护的是外部的app，其中app包含use cases或者叫做application services层以及domain层；adapter能够了解为将内部依赖进行适配，实现port层定义的接口。 ...

DDD LiteDDD 畛域驱动设计的小名大家应该都有所耳闻，然而理论我的项目残缺落地 DDD 的很少。因为 DDD 概念繁冗，畛域、子域、外围子域、通用子域、实体、值对象、畛域服务、应用服务、畛域事件、上下文等一大堆概念，间接把人绕晕，对应到理论业务模型时，横看成岭侧成峰，开发人员外部都难以达成统一。 因为 DDD 设计之初指标是作为简单软件解决之道，但咱们大部分利用并没有那么简单，一个简略的利用应用这么一套简单的概念，有点画蛇添足。在微服务时代，设计准则就是依据畛域划分上下文，单体利用复杂度大大降低，微服务须要一种精简的架构。 这里我提出轻量级 DDD 架构： DDD Lite，让其更好的符合微服务。 分层架构在 MVC 中就被宽泛采纳，DDD 中也有四层架构、五层架构、六边形架构等多种流派。 DDD Lite 采纳较为简单的四层架构，自上而下为： InterfaceServiceModelInfrastructure分层Interface接口层。 对外提供 HTTP，RPC 等接口，参数校验、编解码等逻辑在本层解决，业务状态码、对外数据结构在本层定义。 Service服务层。 次要业务逻辑层，调用 Model 层 Repository 接口实现畛域业务逻辑，事务组装。一个 Service 对应一个畛域，畛域是指类似业务逻辑的归类。一个微服务个别只有一到两个 Service，不宜过多。 Model数据模型层。 定义数据结构，以及数据模型对应的 Repository 接口，但不蕴含具体实现。多个相干 Model 组成畛域，此处对畛域进行简化，不再纠结于子域、实体、值对象等细粒度概念。围绕 Model 定义 Repository 接口，不掺杂业务逻辑，供 Service 层调用，不便在 Service 层组成事务。 Repository pattern这里独自讲一下 Repository 设计模式，这是设计好数据模型的重中之重。 Repository 模式即是将对数据结构的操作形象成接口，将业务逻辑（business logic）和数据处理（data access）拆散，退出了一个形象层。 有了 Repository 接口，依赖就从具体变成形象，和 DB 等根底层依赖解耦，不便施行 TDD（测试驱动开发）。 Repository 接口应该放弃细粒度，设计得足够通用，缩小业务属性，不便复用。 Infrastructure基础设施层。 实现 Model 层 Repository 接口，对接 DB、MQ 等数据长久化，或者 RPC 近程调用后端服务。 ...