Questions tagged «onion-architecture»

的清洁体系结构建议让交互器调用实际执行的演示者（其被注入时，DIP以下）的处理响应/显示的用例。但是，我看到人们实现了这种体系结构，从交互器返回输出数据，然后让控制器（在适配器层中）决定如何处理它。除了没有明确定义交互器的输入和输出端口之外，第二种解决方案是否将应用程序职责泄漏到应用程序层之外？ 输入和输出端口 考虑到Clean Architecture的定义，尤其是描述控制器，用例交互器和演示者之间关系的小流程图，我不确定我是否正确理解“用例输出端口”应该是什么。 像六边形体系结构一样，干净的体系结构区分主要端口（方法）和次要端口（由适配器实现的接口）。按照通信流程，我希望“用例输入端口”是主要端口（因此只是一个方法），而“用例输出端口”是要实现的接口，也许是使用实际适配器的构造函数参数，以便交互器可以使用它。 代码示例 举例来说，这可能是控制器代码： Presenter presenter = new Presenter(); Repository repository = new Repository(); UseCase useCase = new UseCase(presenter, repository); useCase->doSomething(); 演示者界面： // Use Case Output Port interface Presenter { public void present(Data data); } 最后，交互器本身： class UseCase { private Repository repository; private Presenter presenter; public UseCase(Repository …

42 architecture  architectural-patterns  onion-architecture 

我看到洋葱架构仅比BL负责在DAL（或DAL的接口）上调用方法进行CRUD的3层架构有所益处。洋葱具有更好的关注点分离，可测试性，可维护性，并且更清洁。 那么，洋葱架构在各个方面是否确实更好，并且3层架构只是做事的一种旧方法，或者在某些情况下，我更喜欢使用3层架构，如果这样-哪个？

11 design  architecture  layers  n-tier  onion-architecture 

您正在建立一个跟踪公司的系统。这些公司有联系人。这些联系人通常都是专家，只回答某些类型的问题，例如帐单/付款，销售，订购和客户支持。 使用域驱动设计和洋葱架构，我使用以下类型对它进行了建模： 公司 有联络人 联系 有联系方式 ContactType（枚举） CompanyRepository（接口） EFCompanyRepository（在外部程序集中定义，使用EntityFramework，实现CompanyRepository） 对于如何为该应用程序建模数据库，我们的团队意见分歧。 A面：精益DDDers： 定义哪些ContactTypes对一个联系人有效是Domain的工作。向数据库中添加表以验证是否未保存未知的ContactType是域泄漏的迹象。它将逻辑传播得太远了。 将静态表添加到数据库和相应的代码是浪费的。在此应用程序中，数据库解决了一个问题：保留事物并将其还给我。编写一个额外的表和相应的CRUD代码很浪费。 更改持久性策略应尽可能容易。更改业务规则的可能性更大。如果我决定SQL Server花费太多，则不需要重新构建放在架构中的所有验证。 B面：传统主义者[这可能不是一个好名字。DBCentrists？]： 在数据库中存储没有读取代码就没有意义的数据是一个坏主意。报表和其他使用者必须自己重复值列表。 按需加载数据库类型字典的代码并不多。不用担心 如果更改的源是代码而不是数据，那么当更改时，我将不得不部署位而不是简单的SQL脚本。 哪一方都不对或错，但从长远来看，其中一方可能会更有效率，计算初始开发，错误等的开发时间。这是哪一方-还是有更好的折衷办法？其他编写这种样式的代码的团队做什么？

10 domain-driven-design  domain-model  onion-architecture