• 豫园商城升级改造:这些楼顶可见最好的风景--旅游频道 2019-05-14
  • 头条 —频道 春城壹网 七彩云南 一网天下 2019-05-14
  • 人为某种意识而奋斗是幸福的,获得成绩或成就更幸福。 2019-05-10
  • 【专题】省违反中央八项规定精神和“四风”问题线索举报平台 2019-05-09
  • 确定这是热身赛?吴前拼到大腿抽筋 拆绷带继续干 2019-05-09
  • 应对排放新规 大众德国工厂计划短暂停产 2019-04-26
  • 一师一团土地确权登记颁证工作全面展开 2019-04-26
  • 一语惊坛(5月31日):“我们不一样”,中国向世界许下一个承诺。 2019-04-22
  • 俄罗斯世界杯F组:球迷风采 2019-04-10
  • 5月份国民经济数据发布:中国经济持续稳中向好 2019-04-10
  • 贵州宣讲十九大:干部争当宣讲员 群众心窝暖洋洋 2019-03-25
  • 别空谈,说说看,这个“简单的逻辑关系”是什么关系? 2019-03-25
  • 快过闪电,MIUI 10与MIUI 9速度对比 2019-03-21
  • 泽州去年“免费教育”资金达5211万元 2019-03-19
  • 看你这么可怜,再提示你一下:你重孙算1,父母为2,父母的父母为4,父母的父母的父母为8…… 2019-03-19
  • Why DDD and layered architecture

    快乐彩开奖号码 www.752o.com As a developer, you may think that your job is to write code. However, Software development is not a product pipeline. If all developers just simply add new features and don’t care about design, software development and maintenance will become more and more complicated. A developer’s job is to solve a problem through software, and coding is just one aspect of software development. Good design and communication are just as important.

    Domain driven design(or DDD) is such approach focused on clear communication and shared domain knowledge.

    The importance of the shared model knowledge

    Before attempting to solve a problem it’s important that we understand the problem correctly. Obviously, if our understanding of the problem is incomplete or distorted, then we won’t to be able to provide a useful solution. And sadly, of course, it’s the developers’ understanding, not the domain experts’s understanding. that gets released to production.
    What if the domain experts,the development team, other stakeholders share the same model? In this case there is no translation from the domain expert’s requirements to the code. The code is designed to reflect the shared model directly.

    The benefits of this approach can be:

    • Faster time to market
    • More business value
    • Less waste
    • Easier maintenance and evolution

    Understanding the Domain through business events

    A DDD approach to gathering requirements will emphasize building a shared understanding between developers and domain experts.
    How to do that? Business logic is not static, it’s a process of transformation, so understanding how it changes is a good starting point. the transformation point of the process is also called domain event. For example “the order submitted” is a domain event will kick off the order selling process.

    Use Event storming to discover the domain

    There are a number of ways to discover events in a domain, but one that is particularly suitable for a DDD approach is Event Storming, which is a collaborative process for discovering business events and their associated workflows. TW Xi’an team did several workshops for Event Storming in the past days.

    Partitioning the Domain into Subdomains

    After Event storming we have a good understanding of what the various business processes are. But the big picture is still quite chaotic. The next step is partitioning the problem domain into smaller subdomains When faced with a large problem, it’s natural to break it into smaller components that can be addressed separately.
    We have a large problem: Selling domain, Can we break it into smaller pieces?
    Yes, we can. We can split it to various aspects of the Order, Charge, Authentication, Availability …, We will call each of these areas a domain.

    Creating a solution Using Bounded contexts

    Understanding the problem doesn’t mean that building a solution is easy. The solution can’t possibly represent all the information in the original domain. We should only capture the information that is relevant to solving a particular problem. Everything else is irrelevant.
    We therefore need to create a distinction between a “problem space” and a “solution space” and they must be treated as two different things. To build the solution we will create a model for the problem domain, extracting only the aspects of the domain that are relevant and then re-creating them in our solution space as bounded context.

    1. Why context

    Because each context represents some specialized knowledge in the solution. Within the context, we share a common language and the design is coherent and unified.

    2. Why bounded

    In the real world, domains have fuzzy boundaries, but in the world of software we want to reduce coupling between separate subsystems so that they can evolve independently.

    Creating a ubiquitous language

    The set of concepts and vocabulary that is shared between everyone on the team is called the Ubiquitous Language. This is the language that defines the shared model for the business domain. The language should used everywhere in the project, not just in the requirements but in the design, and most importantly, in the source code.
    Finally, it’s important to realize that you often cannot have a single Ubiquitous language that covers all domains and contexts.
    We called User in Authentication domain but called Customer in Order domain.

    Domain modeling

    We have now got a basic understanding of Domain, but how to document them?
    we should use visual diagrams, but these are often hard to work with and not detailed enough to capture some of the subtleties of the domain.
    If you have a lot of database experience, your first instinct might be think about tables and the relationships between them. You might envision a Order table, an order line table, and Customer, Contact tables. And then you’ll probably want to describe the relationships between them by foreign key, But if you do this, you are making a mistake. In DDD we let the domain drive the design, not a database schema.
    In DDD terminology this step called Domain modeling, For developer we should use code to modeling these domains.

    Other concepts

    As you know DDD is a large topic, We can not describe all the concepts in here. But you should understand that the core idea of DDD is using code to create a business model that can be shared with domain experts.
    Other concepts like Entity, ValueObject, AggregateRoot, CQRS, EventSourcing, MicroService etc require you constantly practice to understand.

    Layered architecture

    For implementing DDD, we need to design our architecture to achieve this goal. The reason we will split whole system into multiple layers is Separation of Concerns and Single Responsibility Principle. The general idea is that we split persistence, rendering api and application logic to different layers and let developers focus on design and writing domain logic.

    Domain Layer

    We have the domain layer and business logic at the center, The domain layer will contain enterprise business logic and types.

    Application Layer

    Contains application logic and types.
    The difference between Domain layer and application layers is Domain layer can be invoked by application layer, But domain layer don't know application layer.

    Infrastructure Layer

    Focus on persistence by database or api

    Invert of Control

    We don't want to let business logic to be dependent on concerns such as infrastructure and persistence so we invert these dependencies, so infrastructure, persistence and presentation all take a dependency on that center area.
    The way we did is we added our abstraction and interfaces inside the core and then infrastructure and persistence implement those abstractions. For example, for persistence, if we were creating a repository there, there would be an IRepository used in the core and in persistence we will implement that IRepository. The result of this design is domain layer doesn't have any dependency on anything, We will got below benefit:

    • It's highly testable, We can actually test the core without UI
    • It's independent of persistence, whatever you persist data by database or api
    • Independent of external system
    posted @ 2018-11-15 15:33 .NET西安社区 阅读(...) 评论(...) 编辑 收藏
  • 豫园商城升级改造:这些楼顶可见最好的风景--旅游频道 2019-05-14
  • 头条 —频道 春城壹网 七彩云南 一网天下 2019-05-14
  • 人为某种意识而奋斗是幸福的,获得成绩或成就更幸福。 2019-05-10
  • 【专题】省违反中央八项规定精神和“四风”问题线索举报平台 2019-05-09
  • 确定这是热身赛?吴前拼到大腿抽筋 拆绷带继续干 2019-05-09
  • 应对排放新规 大众德国工厂计划短暂停产 2019-04-26
  • 一师一团土地确权登记颁证工作全面展开 2019-04-26
  • 一语惊坛(5月31日):“我们不一样”,中国向世界许下一个承诺。 2019-04-22
  • 俄罗斯世界杯F组:球迷风采 2019-04-10
  • 5月份国民经济数据发布:中国经济持续稳中向好 2019-04-10
  • 贵州宣讲十九大:干部争当宣讲员 群众心窝暖洋洋 2019-03-25
  • 别空谈,说说看,这个“简单的逻辑关系”是什么关系? 2019-03-25
  • 快过闪电,MIUI 10与MIUI 9速度对比 2019-03-21
  • 泽州去年“免费教育”资金达5211万元 2019-03-19
  • 看你这么可怜,再提示你一下:你重孙算1,父母为2,父母的父母为4,父母的父母的父母为8…… 2019-03-19
  • 体彩排列五 重庆时时彩单双开奖时间 体彩p3开奖号码 pk10长龙投注技巧 玩北京pk10输钱经历 金山彩票中奖怎么领奖 超级大乐透开奖号码 刮刮乐奖项设置 报码聊天室 足彩4场进球中奖计算 山西快乐十分开奖 重庆幸运农场好假啊! 河南体彩481 足彩混合过关方式 福建体育彩票31选7 11选5涵数运算公式