为了保护合理的依附关系，依附注入(Depedency Injection)是须要经常采取的实现模式，它作为解耦合的一种办法信赖大年夜家都不会陌生，具体定义拜见 这里 。
在测试构建时，我们应用了一个IoC框架(依附注入的实现)来构造了一个Api，并且把相干的依附(如CargoService)注入给了这个Api。如许既没有破坏Interface和Service的单向依附关系，又解决了测试过程中Api的实例化请求。
- auto provider = std::make_shared< StubCargoProvider >();
- api::Api* createApi() {
- ContainerBuilder builder;
- builder.registerType< CargoRepository >().singleInstance();
- builder.registerInstance(provider).as<CargoProvider>();
- builder.registerType< CargoService >().singleInstance();
- builder.registerType<api::Api>().singleInstance();
- auto container = builder.build();
- std::shared_ptr<api::Api> api = container->resolve<api::Api>();
- return api.get();
- }
膳绫擎测试了收到一条创建信息后实例化一个Cargo的简单场景，请求创建后的Cargo的标识id跟信息里的一致，并且出货的日期一致。这个测试驱动出来一个Interface的Api::CreateCargo。
测试实现
有了范畴模型，大年夜家天然会想着若何去实现营业应用了，而实现应用的过程中必定会推敲到单位测试的设计。在构建高质量软件过程中，单位测试已经成为了标准规范，但高质量的单位测试倒是困扰很多团队的广泛问题。很多时刻设计测试比实现应用本身加倍艰苦。
这里很难有一个固定标准来评判某个时光点的单位测试质量，但一个核心的原则是让用例尽量测试营业需求而不是实现方法本身。知足营业需求是我们的目标，实现方法可能有多种，我们不欲望须要持续重构的实现代码影响到我们的测试用例。比如针对实现过程中的某个函数进行入参和出参的单位测试，当这个函数产生一点改变(即使是重定名)，我们也须要修改测试。
测试驱动开辟TDD无疑是一种好的实践，如不雅应用合适，它确切可以或许实现我们上述的原则，并且可以或许赞助我们交换营业的需求。比较有意思的是，在基于DDD建立的核心模型之上应用TDD似乎加倍瓜熟蒂落。类比DDD和TDD固然是不恰当的，但我们会发明两者在遵守的原则上是一致的，即都是面向营业做分化和设计：DDD就全部营业问题域进行了分化，形成子问题域;TDD就营业需求在实现时进行义务分化，大年夜简单场景到复杂场景慢慢经由过程测试驱动出实现。下面的测试用例展示了在核心模型上的TDD过程。
经久以来对于TDD这个实践大年夜家都有架构设计上的困惑，很多资深架构师担心完全大年夜营业需求驱动出实现没法形成有效的技巧架构，并且每次实现的重构成本都可能很高。DDD的惹人大年夜某种程度上解决了这个挂念，经由过程前期的┞方略和战术建模肯定了核心范畴架构，这个架构是经由过程预先综合评论辩论决定计划的，推敲了更广阔的营业问题，较之TDD应用的营业需求层面加倍宏不雅。在已有核心模型基本上我们也会发明测试用例的设计更轻易大年夜应用视角出发，大年夜而降低了测试设计的难度。
关于预先设计
如不雅没有读计谋篇直接看本文的读者肯定会提出关于预先设计的挂念，毕竟DDD是被敏捷开辟圈子承认的一种架构方法，其目标应当是构建架构模型的响应力。而这里给大年夜家的更多是模式化的实现过程，好像彷佛大年夜建模到代码一切都预先设计好了。
推荐阅读
知道什么时刻做什么 【编辑推荐】JetBrains 的 Go 集成开辟情况已肯定最终名称：GoLandJDK 10 早期试用版宣布，Java 开辟对象包高等码农进步90%开辟效力的对象推荐晋升Web开辟机能的10个技>>>详细阅读
本文标题：DDD实战篇：分层架构的代码结构
地址：http://www.17bianji.com/lsqh/38634.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示